RE: Please help clarify or confirm -- HttpSession
Craig, Maybe single sign-on is the wrong term to use. We are essentially trying to create a single 'point of entry' into our client website that will authenticate/authorize a user to those webapps that they are allowed to access. Within this desire, I also need to maintain a distinct separation between my lines of business, even though a user can have access to webapp1 in business 1, webapp1 in business2, etc. In my authentication procedure, I build a set of nested beans for the user, something along the lines of user +--- business --- business --- business +webapp +webapp +webapp +webapp +webapp +webapp ... ... Within each webapp bean is a list of validation codes that permit the user to access enterprise data. Each webapp is responsible for extracting this list of codes (by webapp by business) and then using this list to retrieve data (typically goes into the WHERE clause on a SELECT statement). By creating this set of nested beans one time (at authentication) was to eliminate the need for each webapp to access our authentication database, thereby (hopefully) allowing each webapp to focus only on the business solution. Finally, by keeping each webapp in a separate directory structure, I was also hoping to 'self contain' each webapp (i.e. each webapp can be modified, tested, etc. without concern about potentially changing other webapps). Am I just really out in left field here? Finally, in regards to the JSP/ASP integration, I've found a product called JIntegra from Intrinsic Systems that provides a bi-directional bridge between Java classes and ASP .COM objects (through the use of DCOM). I think that by using a static class in a common classloader would also provide the functionality (within the Java class) to talk to my .ASP webapps. Has anyone out there used this product before? Any feedback? Jerry -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 10:51 PM To: Struts Users Mailing List Cc: '[EMAIL PROTECTED]' Subject: RE: Please help clarify or confirm -- HttpSession On Thu, 13 Jun 2002, Jerry Jalenak wrote: Date: Thu, 13 Jun 2002 13:12:00 -0500 From: Jerry Jalenak [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED], '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: RE: Please help clarify or confirm -- HttpSession A couple of reasons 1. My company has three main lines of business that for various regulatory reasons need to be kept separate. This applies to deliver of content on the web as well. What I am trying to accomplish is essentially a single-signon capability (within the framework) that the business applications can then validate against (successful logon, etc.). Single sign on is a different kettle of fish ... and it does *not* require sharing sessions for the server to accomodate it. Tomcat 4, for example, supports single sign on -- see the server config documents on the Host element of server.xml for the details. All this does for you, though, is avoid the need for a user to log in to each app -- it does nothing for sharing information between apps. Your best bet is to do something like: * Store the shared info in a database or EJB that is accessible to all the relevant webapps. * Store shared information in a static variable associated with a class that is loaded from the shared class loader (so that there really is only one instance). Figuring out how to relate the information from various webapps together is an exercise left to the user, but you can probably do something with the fact that request.getRemoteUser() will return the same value in every webapp. 2. I am also needing to integrate non-JSP applications (.ASP for instance) into the framework. I know they cannot directly access my JavaBeans, but I'm wondering if a .ASP page could access the HttpSession data. I don't have a clue how you could possibly accomplish this, given that the ASP pages aren't running inside the same JVM that Tomcat is. Jerry Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] This transmission (and any information attached to it) may be confidential and is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient or the person responsible for delivering the transmission to the intended recipient, be advised that you have received this transmission in error and that any use, dissemination, forwarding, printing, or copying of this information is strictly prohibited. If you have received this transmission in error, please immediately notify LabOne at (800)388-4675. -- To unsubscribe, e-mail
RE: Please help clarify or confirm -- HttpSession
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]
Re: Please help clarify or confirm -- HttpSession
At my knowledge, under tomcat each webapp have his own memory space so you can't share HttpSession between 2 webapp. You can share object between 2 webapp with one condition, the class to be shared must be loaded in same ClassLoader. Did you understand my english ;) -Emmanuel --- Yuan, Tony [EMAIL PROTECTED] a écrit : Hi Guys, Can anyone help clarify or confirm the relationship between an HttpSession and a web application? I mean, can two WAR (two application) share one common HttpSession and whatever resource this HttpSession contains? My understanding is that if WARs are deployed separately, then there will be different HttpSessions and therefore you can not share resources among them. Can anyone help confirm this? or correct if I am wrong? Thanks! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Please help clarify or confirm -- HttpSession
This is something I've wondered about, especially in a team development environment where there are several programmers working on different webapps that need to share a common framework - in other words, something like this: Tomcat\webapps framework-application WEB-INF ... webapplication_1 WEB-INF ... webapplication_2 WEB-INF ... etc etc etc Can the classes in webapplication_1 'see' session data that was created and stored in the session by the framework-application? Jerry -Original Message- From: emmanuel.boudrant [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 12:39 PM To: Struts Users Mailing List Subject: Re: Please help clarify or confirm -- HttpSession At my knowledge, under tomcat each webapp have his own memory space so you can't share HttpSession between 2 webapp. You can share object between 2 webapp with one condition, the class to be shared must be loaded in same ClassLoader. Did you understand my english ;) -Emmanuel --- Yuan, Tony [EMAIL PROTECTED] a écrit : Hi Guys, Can anyone help clarify or confirm the relationship between an HttpSession and a web application? I mean, can two WAR (two application) share one common HttpSession and whatever resource this HttpSession contains? My understanding is that if WARs are deployed separately, then there will be different HttpSessions and therefore you can not share resources among them. Can anyone help confirm this? or correct if I am wrong? Thanks! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] This transmission (and any information attached to it) may be confidential and is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient or the person responsible for delivering the transmission to the intended recipient, be advised that you have received this transmission in error and that any use, dissemination, forwarding, printing, or copying of this information is strictly prohibited. If you have received this transmission in error, please immediately notify LabOne at (800)388-4675. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Please help clarify or confirm -- HttpSession
You can with this : Foo foo = ... HttpSession session = request.getSession(); session.setAttribute(foo,foo); getServlet().getServletContext().getContext(/webapplication1).forward(request,reponse); But Foo.class must be loader in same ClassLoader foreach application. The problem is under Tomcat, each application has a differents ClassLoader. So you must put Foo.class in Tomcat\common\lib. If the class is already loaded in Tomcat ClassLoader, it won't be in your webapp ClassLoader. If not, you have a ClassClastException. -Emmanuel --- Jerry Jalenak [EMAIL PROTECTED] a écrit : This is something I've wondered about, especially in a team development environment where there are several programmers working on different webapps that need to share a common framework - in other words, something like this: Tomcat\webapps framework-application WEB-INF ... webapplication_1 WEB-INF ... webapplication_2 WEB-INF ... etc etc etc Can the classes in webapplication_1 'see' session data that was created and stored in the session by the framework-application? Jerry -Original Message- From: emmanuel.boudrant [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 12:39 PM To: Struts Users Mailing List Subject: Re: Please help clarify or confirm -- HttpSession At my knowledge, under tomcat each webapp have his own memory space so you can't share HttpSession between 2 webapp. You can share object between 2 webapp with one condition, the class to be shared must be loaded in same ClassLoader. Did you understand my english ;) -Emmanuel --- Yuan, Tony [EMAIL PROTECTED] a écrit : Hi Guys, Can anyone help clarify or confirm the relationship between an HttpSession and a web application? I mean, can two WAR (two application) share one common HttpSession and whatever resource this HttpSession contains? My understanding is that if WARs are deployed separately, then there will be different HttpSessions and therefore you can not share resources among them. Can anyone help confirm this? or correct if I am wrong? Thanks! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] This transmission (and any information attached to it) may be confidential and is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient or the person responsible for delivering the transmission to the intended recipient, be advised that you have received this transmission in error and that any use, dissemination, forwarding, printing, or copying of this information is strictly prohibited. If you have received this transmission in error, please immediately notify LabOne at (800)388-4675. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Please help clarify or confirm -- HttpSession
In general, there is no way session info from one webapp can be made visible to other webapps. Some details of this may vary depending on your app server. Sessions are controlled by cookies being set on the client. The cookies that are set by each webapp are scoped for that webapp only. As an example, create the following .jsp file and name it session.jsp. Put it in webapp1 html head titleTesting Session Management/title /head body % out.print(Session ID = + request.getSession().getId() ); % /body /html Then, if you were to do a low-level http request from the server, you'd see something like: bash-2.05$ ./telnet -E localhost 8080 [ -- I type ] Trying 127.0.0.1... Connected to localhost. Escape character is 'off'. GET /webapp1/session.jsp HTTP/1.0 [ -- I type ] HTTP/1.1 200 OK Content-Type: text/html;charset=ISO-8859-1 Date: Wed, 12 Jun 2002 00:39:49 GMT Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector) Connection: close Set-Cookie: JSESSIONID=AC75B22FD1D283D1CEF0136928110679;Path=/webapp1 html head titleTesting Session Management/title /head body Session ID = AC75B22FD1D283D1CEF0136928110679 /body /html Connection closed by foreign host. bash-2.05$ The JSESSIONID cookie is used by the servlet container to manage the user session. Notice that the the scope of the JSESSIONID Cookie in this example is limited to the '/webapp1' web application. So even if you have many web applications (or Struts applications) deployed in a servlet container, session tracking is isolated between them. ShamelessPlug I'll be covering topics such as this and others in my upcoming book Struts: Rapid Working Knowledge to be published by SAMS later this year. /ShamelessPlug HTH, Kevin Jerry Jalenak [EMAIL PROTECTED] on 06/13/2002 01:43:50 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] cc:(bcc: Kevin Bedell/Systems/USHO/SunLife) Subject: RE: Please help clarify or confirm -- HttpSession This is something I've wondered about, especially in a team development environment where there are several programmers working on different webapps that need to share a common framework - in other words, something like this: Tomcat\webapps framework-application WEB-INF ... webapplication_1 WEB-INF ... webapplication_2 WEB-INF ... etc etc etc Can the classes in webapplication_1 'see' session data that was created and stored in the session by the framework-application? Jerry -Original Message- From: emmanuel.boudrant [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 12:39 PM To: Struts Users Mailing List Subject: Re: Please help clarify or confirm -- HttpSession At my knowledge, under tomcat each webapp have his own memory space so you can't share HttpSession between 2 webapp. You can share object between 2 webapp with one condition, the class to be shared must be loaded in same ClassLoader. Did you understand my english ;) -Emmanuel --- Yuan, Tony [EMAIL PROTECTED] a écrit : Hi Guys, Can anyone help clarify or confirm the relationship between an HttpSession and a web application? I mean, can two WAR (two application) share one common HttpSession and whatever resource this HttpSession contains? My understanding is that if WARs are deployed separately, then there will be different HttpSessions and therefore you can not share resources among them. Can anyone help confirm this? or correct if I am wrong? Thanks! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] This transmission (and any information attached to it) may be confidential and is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient or the person responsible for delivering the transmission to the intended recipient, be advised that you have received this transmission in error and that any use, dissemination, forwarding, printing, or copying of this information is strictly prohibited. If you have received this transmission in error, please immediately notify LabOne at (800)388-4675. -- 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]
RE: Please help clarify or confirm -- HttpSession
hmmm...but the sessionIDs have to be unique, even across web apps., correct? 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. 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. Am I missing something here? (besides why the hell you would want to do this) :) joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 10:46 AM To: Struts Users Mailing List Subject: RE: Please help clarify or confirm -- HttpSession In general, there is no way session info from one webapp can be made visible to other webapps. Some details of this may vary depending on your app server. Sessions are controlled by cookies being set on the client. The cookies that are set by each webapp are scoped for that webapp only. As an example, create the following .jsp file and name it session.jsp. Put it in webapp1 html head titleTesting Session Management/title /head body % out.print(Session ID = + request.getSession().getId() ); % /body /html Then, if you were to do a low-level http request from the server, you'd see something like: bash-2.05$ ./telnet -E localhost 8080 [ -- I type ] Trying 127.0.0.1... Connected to localhost. Escape character is 'off'. GET /webapp1/session.jsp HTTP/1.0 [ -- I type ] HTTP/1.1 200 OK Content-Type: text/html;charset=ISO-8859-1 Date: Wed, 12 Jun 2002 00:39:49 GMT Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector) Connection: close Set-Cookie: JSESSIONID=AC75B22FD1D283D1CEF0136928110679;Path=/webapp1 html head titleTesting Session Management/title /head body Session ID = AC75B22FD1D283D1CEF0136928110679 /body /html Connection closed by foreign host. bash-2.05$ The JSESSIONID cookie is used by the servlet container to manage the user session. Notice that the the scope of the JSESSIONID Cookie in this example is limited to the '/webapp1' web application. So even if you have many web applications (or Struts applications) deployed in a servlet container, session tracking is isolated between them. ShamelessPlug I'll be covering topics such as this and others in my upcoming book Struts: Rapid Working Knowledge to be published by SAMS later this year. /ShamelessPlug HTH, Kevin Jerry Jalenak [EMAIL PROTECTED] on 06/13/2002 01:43:50 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] cc:(bcc: Kevin Bedell/Systems/USHO/SunLife) Subject: RE: Please help clarify or confirm -- HttpSession This is something I've wondered about, especially in a team development environment where there are several programmers working on different webapps that need to share a common framework - in other words, something like this: Tomcat\webapps framework-application WEB-INF ... webapplication_1 WEB-INF ... webapplication_2 WEB-INF ... etc etc etc Can the classes in webapplication_1 'see' session data that was created and stored in the session by the framework-application? Jerry -Original Message- From: emmanuel.boudrant [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 12:39 PM To: Struts Users Mailing List Subject: Re: Please help clarify or confirm -- HttpSession At my knowledge, under tomcat each webapp have his own memory space so you can't share HttpSession between 2 webapp. You can share object between 2 webapp with one condition, the class to be shared must be loaded in same ClassLoader. Did you understand my english ;) -Emmanuel --- Yuan, Tony [EMAIL PROTECTED] a écrit : Hi Guys, Can anyone help clarify or confirm the relationship between an HttpSession and a web application? I mean, can two WAR (two application) share one common HttpSession and whatever resource this HttpSession contains? My understanding is that if WARs are deployed separately, then there will be different HttpSessions and therefore you can not share resources among them. Can anyone help confirm this? or correct if I am wrong? Thanks! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] This transmission (and any information attached to it) may be confidential and is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient or the person
RE: Please help clarify or confirm -- HttpSession
A couple of reasons 1. My company has three main lines of business that for various regulatory reasons need to be kept separate. This applies to deliver of content on the web as well. What I am trying to accomplish is essentially a single-signon capability (within the framework) that the business applications can then validate against (successful logon, etc.). It may be possible to have the individuals sign in to the default web app and access it through the URI of just / (instead of a URI such as /myWebApp. I believe this may scope the JSESSIONID cookie to / and have it returned to all webapps on the system. I have not tried this and don't know if it will work - though it would be easy to test. 2. I am also needing to integrate non-JSP applications (.ASP for instance) into the framework. I know they cannot directly access my JavaBeans, but I'm wondering if a .ASP page could access the HttpSession data. Can you say, Web Sevices? To begin, look at the Apache SOAP project (now extended under the Jakarta Axis project). Jerry Good luck, Kevin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Please help clarify or confirm -- HttpSession
Kevin, I actually thought about the EJB solution, but we are trying to do this on the cheap without having to buy an EJB container (i.e. JBOSS). Something I was wondering about though - is it possible to run an EAR structure under Tomcat? I'm not very familiar with EJB, so forgive me if I sound stupid here, but is it possible to create a pseudo-J2EE environment and create an Entity-Bean that can do this? The XML-Soap solution also is appealing, but we would like to be able to integrate these various app's with a minimum of re-write. Jerry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 1:18 PM To: Struts Users Mailing List Subject: RE: Please help clarify or confirm -- HttpSession The container makes sure that Session ID's are unique. It sets the cookie as well - nothing in the webapp has to do this. This is just how the containers work. Regarding storing objects from webapp A in a shared classloader class keyed by the sessionID and retrieve them from webapp B. First, you can't physically store an object in another webapp because the memory spaces are isolated from each other. Second, having common directories on the two CLASSPATHS for the two webapps allows you to load CLASSES to create new objects, but not to share the objects once they are created. But there are ways to share objects (in addition to classes) between webapps. And at times there may be good reasons to do so. For example, imagine you have an object representing a transaction to be executed on your system (maybe a stock trade). What if: - The user who entered the transaction wants to see its real-time status. - A trader who is going to execute the transaction needs to see it, and - An auditor needs to monitor all trades currently in the system. Imagine also you want them to use three seperate webapps (or non-servlet applications) to do their work. While not the only approach, it is possible to have all access the same physical Java object. Here are some ways: 1. Implement the Object as an Entity EJB in an EJB container such as JBOSS. Have all the webapps (or whatever) connect to the same EJB Container instance and manipulate the data in the object. The EJB container will manage locking and transactional integrity for you as well. 2. Create the object as a singleton in some JVM somewhere and wrap an RMI server around it. This is basically a hack, but I saw it done once to allow clustered applications to share Properties objects between them (ensuring they were all using the same Properties). (And, yes - it was a pain.) 3. Put the object behind a web service and access it via SOAP. This allows some of the clients to be non-Java. All these solutions are based on putting the object in some place OUTSIDE any of the individual webapps. Joseph Barefoot [EMAIL PROTECTED] on 06/13/2002 02:09:43 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] cc:(bcc: Kevin Bedell/Systems/USHO/SunLife) Subject: RE: Please help clarify or confirm -- HttpSession hmmm...but the sessionIDs have to be unique, even across web apps., correct? 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. 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. Am I missing something here? (besides why the hell you would want to do this) :) joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 10:46 AM To: Struts Users Mailing List Subject: RE: Please help clarify or confirm -- HttpSession In general, there is no way session info from one webapp can be made visible to other webapps. Some details of this may vary depending on your app server. Sessions are controlled by cookies being set on the client. The cookies that are set by each webapp are scoped for that webapp only. As an example, create the following .jsp file and name it session.jsp. Put it in webapp1 html head titleTesting Session Management/title /head body % out.print(Session ID = + request.getSession().getId() ); % /body /html Then, if you were to do a low-level http request from the server, you'd see something like: bash-2.05$ ./telnet -E localhost 8080 [ -- I type ] Trying 127.0.0.1... Connected to localhost. Escape character is 'off'. GET /webapp1/session.jsp HTTP/1.0 [ -- I type ] HTTP/1.1 200 OK Content-Type: text/html;charset=ISO-8859-1 Date: Wed, 12 Jun 2002 00:39:49 GMT Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector) Connection: close Set-Cookie: JSESSIONID=AC75B22FD1D283D1CEF0136928110679;Path=/webapp1 html head titleTesting Session Management/title /head body
Re: Please help clarify or confirm -- HttpSession
I came across a similar situation recently. We have a major asp application that we are slowly converting to jsp/struts/java. So - we need the two technologies to talk to one another... We use microsoft's msxml object to post data to a url/page, and then wait for a response. If the asp page needs to access the jsp's session data - what you could do is perform an empty post to the jsp page, which would execute the jsp page... in turn the jsp page would read the session data and convert it to name/value pairs and output it as a string - allowing the asp page to pickup the string (...read the response) and parse it just like a normal post this is just one idea... not sure what limitations may be imposed on your project so this may or may not work for you... - Scott. - Original Message - From: Jerry Jalenak [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, June 13, 2002 2:32 PM Subject: RE: Please help clarify or confirm -- HttpSession I did find a product called JIntegra (from a different posting a few days ago) that I think will allow the .ASP apps to access a Java class through some sort of smoke-and-mirror arrangement. I'm not sure if this will work across servers - if it does then I'm home free. If not, then it's back to XML. Anyway, back to the original question, I was also thinking about ease of code maintainability. If a webapp needs to be 'pulled' out and modified, wouldn't it be easier to do if the webapp was self-contained? That way a programmer could ensure that they have everything related to the webapp (checked out through CVS), modify it, test, and then return the webapp to a production status. Jerry -Original Message- From: Joseph Barefoot [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 1:27 PM To: Struts Users Mailing List Subject: RE: Please help clarify or confirm -- HttpSession wo-boy! Sounds like fun, Jerry, good luck! I think maybe you could store a UserRole object using a static or singleton class in a shared classloader. Should be pretty easy to test out with your setup (just try to store something in the shared class from one webapp and retrieve it from the other). I haven't a clue about ASPs accessing the session data though...perhaps by XML messaging through sockets? That would mean that any session data you wanted to share would have to be easily converted to an XML format, however, both in Java-land and ASP-land, and the conversion fairly swift. If you just wanted it for authentication purposes, might not be too difficult though. All of this depends on where the ASP application is running relative to the Java apps. too though. Much easier if they are both behind the same firewall (no encryption worries). peace, Joe Barefoot -Original Message- From: Jerry Jalenak [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 11:12 AM To: 'Struts Users Mailing List'; '[EMAIL PROTECTED]' Subject: RE: Please help clarify or confirm -- HttpSession A couple of reasons 1. My company has three main lines of business that for various regulatory reasons need to be kept separate. This applies to deliver of content on the web as well. What I am trying to accomplish is essentially a single-signon capability (within the framework) that the business applications can then validate against (successful logon, etc.). 2. I am also needing to integrate non-JSP applications (.ASP for instance) into the framework. I know they cannot directly access my JavaBeans, but I'm wondering if a .ASP page could access the HttpSession data. Jerry -Original Message- From: Joseph Barefoot [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 1:10 PM To: Struts Users Mailing List Subject: RE: Please help clarify or confirm -- HttpSession hmmm...but the sessionIDs have to be unique, even across web apps., correct? 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. 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. Am I missing something here? (besides why the hell you would want to do this) :) joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 10:46 AM To: Struts Users Mailing List Subject: RE: Please help clarify or confirm -- HttpSession In general, there is no way session info from one webapp can be made visible to other webapps. Some details of this may vary depending on your app server. Sessions are controlled by cookies being set on the client. The cookies that are set by each webapp are scoped for that webapp only. As an example, create
RE: Please help clarify or confirm -- HttpSession
The container makes sure that Session ID's are unique. It sets the cookie as well - nothing in the webapp has to do this. This is just how the containers work. Of course. Regarding storing objects from webapp A in a shared classloader class keyed by the sessionID and retrieve them from webapp B. First, you can't physically store an object in another webapp because the memory spaces are isolated from each other. Second, having common directories on the two CLASSPATHS for the two webapps allows you to load CLASSES to create new objects, but not to share the objects once they are created. True, but not what I suggested at all. Two webapps sharing a common CLASSPATH is far different from them having access to a common (shared,parent) CLASSLOADER. In the former two different classloaders are loading the same class into two different memory spaces, as you say. In the latter, a parent classloader is loading a class into a memory space accessible by either of the two child classloaders for the webapps. So I fail to see why a static class with static resources loaded by this parent classloader will not enable objects to be shared between the two child classloaders, so long as the objects themselves are also created from classes loaded by the shared classloader. Note that I am also not claiming that this will 100% work, I just don't see why it wouldn't. But there are ways to share objects (in addition to classes) between webapps. And at times there may be good reasons to do so. For example, imagine you have an object representing a transaction to be executed on your system (maybe a stock trade). What if: - The user who entered the transaction wants to see its real-time status. - A trader who is going to execute the transaction needs to see it, and - An auditor needs to monitor all trades currently in the system. Imagine also you want them to use three seperate webapps (or non-servlet applications) to do their work. While not the only approach, it is possible to have all access the same physical Java object. Here are some ways: 1. Implement the Object as an Entity EJB in an EJB container such as JBOSS. Have all the webapps (or whatever) connect to the same EJB Container instance and manipulate the data in the object. The EJB container will manage locking and transactional integrity for you as well. 2. Create the object as a singleton in some JVM somewhere and wrap an RMI server around it. This is basically a hack, but I saw it done once to allow clustered applications to share Properties objects between them (ensuring they were all using the same Properties). (And, yes - it was a pain.) 3. Put the object behind a web service and access it via SOAP. This allows some of the clients to be non-Java. All these solutions are based on putting the object in some place OUTSIDE any of the individual webapps. Putting an object into a shared classloader DOES put it OUTSIDE of any of the individual webapps, in that that object's existence is not dependent on the existence of any webapp. If this were not true, then the classloader hierarchy employed by app. servers would be meaningless. peace, joe Joseph Barefoot [EMAIL PROTECTED] on 06/13/2002 02:09:43 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] cc:(bcc: Kevin Bedell/Systems/USHO/SunLife) Subject: RE: Please help clarify or confirm -- HttpSession hmmm...but the sessionIDs have to be unique, even across web apps., correct? 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. 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. Am I missing something here? (besides why the hell you would want to do this) :) joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 10:46 AM To: Struts Users Mailing List Subject: RE: Please help clarify or confirm -- HttpSession In general, there is no way session info from one webapp can be made visible to other webapps. Some details of this may vary depending on your app server. Sessions are controlled by cookies being set on the client. The cookies that are set by each webapp are scoped for that webapp only. As an example, create the following .jsp file and name it session.jsp. Put it in webapp1 html head titleTesting Session Management/title /head body % out.print(Session ID = + request.getSession().getId() ); % /body /html Then, if you were to do a low-level http request from the server, you'd see something like: bash-2.05$ ./telnet -E localhost 8080 [ -- I type ] Trying 127.0.0.1... Connected
RE: Please help clarify or confirm -- HttpSession
Huh? JBoss is FREE. -Original Message- From: Jerry Jalenak [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 2:41 PM To: 'Struts Users Mailing List' Subject: RE: Please help clarify or confirm -- HttpSession Kevin, I actually thought about the EJB solution, but we are trying to do this on the cheap without having to buy an EJB container (i.e. JBOSS). Something I was wondering about though - is it possible to run an EAR structure under Tomcat? I'm not very familiar with EJB, so forgive me if I sound stupid here, but is it possible to create a pseudo-J2EE environment and create an Entity-Bean that can do this? The XML-Soap solution also is appealing, but we would like to be able to integrate these various app's with a minimum of re-write. Jerry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 1:18 PM To: Struts Users Mailing List Subject: RE: Please help clarify or confirm -- HttpSession The container makes sure that Session ID's are unique. It sets the cookie as well - nothing in the webapp has to do this. This is just how the containers work. Regarding storing objects from webapp A in a shared classloader class keyed by the sessionID and retrieve them from webapp B. First, you can't physically store an object in another webapp because the memory spaces are isolated from each other. Second, having common directories on the two CLASSPATHS for the two webapps allows you to load CLASSES to create new objects, but not to share the objects once they are created. But there are ways to share objects (in addition to classes) between webapps. And at times there may be good reasons to do so. For example, imagine you have an object representing a transaction to be executed on your system (maybe a stock trade). What if: - The user who entered the transaction wants to see its real-time status. - A trader who is going to execute the transaction needs to see it, and - An auditor needs to monitor all trades currently in the system. Imagine also you want them to use three seperate webapps (or non-servlet applications) to do their work. While not the only approach, it is possible to have all access the same physical Java object. Here are some ways: 1. Implement the Object as an Entity EJB in an EJB container such as JBOSS. Have all the webapps (or whatever) connect to the same EJB Container instance and manipulate the data in the object. The EJB container will manage locking and transactional integrity for you as well. 2. Create the object as a singleton in some JVM somewhere and wrap an RMI server around it. This is basically a hack, but I saw it done once to allow clustered applications to share Properties objects between them (ensuring they were all using the same Properties). (And, yes - it was a pain.) 3. Put the object behind a web service and access it via SOAP. This allows some of the clients to be non-Java. All these solutions are based on putting the object in some place OUTSIDE any of the individual webapps. Joseph Barefoot [EMAIL PROTECTED] on 06/13/2002 02:09:43 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] cc:(bcc: Kevin Bedell/Systems/USHO/SunLife) Subject: RE: Please help clarify or confirm -- HttpSession hmmm...but the sessionIDs have to be unique, even across web apps., correct? 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. 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. Am I missing something here? (besides why the hell you would want to do this) :) joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 10:46 AM To: Struts Users Mailing List Subject: RE: Please help clarify or confirm -- HttpSession In general, there is no way session info from one webapp can be made visible to other webapps. Some details of this may vary depending on your app server. Sessions are controlled by cookies being set on the client. The cookies that are set by each webapp are scoped for that webapp only. As an example, create the following .jsp file and name it session.jsp. Put it in webapp1 html head titleTesting Session Management/title /head body % out.print(Session ID = + request.getSession().getId() ); % /body /html Then, if you were to do a low-level http request from the server, you'd see something like: bash-2.05$ ./telnet -E localhost 8080 [ -- I type ] Trying 127.0.0.1... Connected to localhost. Escape character is 'off'. GET /webapp1/session.jsp HTTP/1.0 [ -- I type ] HTTP/1.1 200 OK Content-Type: text/html;charset=ISO-8859-1 Date: Wed, 12 Jun 2002 00:39:49
RE: Please help clarify or confirm -- HttpSession
Free? Didn't realize that.. -Original Message- From: Jerome Jacobsen [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 1:50 PM To: Struts Users Mailing List Subject: RE: Please help clarify or confirm -- HttpSession Huh? JBoss is FREE. -Original Message- From: Jerry Jalenak [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 2:41 PM To: 'Struts Users Mailing List' Subject: RE: Please help clarify or confirm -- HttpSession Kevin, I actually thought about the EJB solution, but we are trying to do this on the cheap without having to buy an EJB container (i.e. JBOSS). Something I was wondering about though - is it possible to run an EAR structure under Tomcat? I'm not very familiar with EJB, so forgive me if I sound stupid here, but is it possible to create a pseudo-J2EE environment and create an Entity-Bean that can do this? The XML-Soap solution also is appealing, but we would like to be able to integrate these various app's with a minimum of re-write. Jerry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 1:18 PM To: Struts Users Mailing List Subject: RE: Please help clarify or confirm -- HttpSession The container makes sure that Session ID's are unique. It sets the cookie as well - nothing in the webapp has to do this. This is just how the containers work. Regarding storing objects from webapp A in a shared classloader class keyed by the sessionID and retrieve them from webapp B. First, you can't physically store an object in another webapp because the memory spaces are isolated from each other. Second, having common directories on the two CLASSPATHS for the two webapps allows you to load CLASSES to create new objects, but not to share the objects once they are created. But there are ways to share objects (in addition to classes) between webapps. And at times there may be good reasons to do so. For example, imagine you have an object representing a transaction to be executed on your system (maybe a stock trade). What if: - The user who entered the transaction wants to see its real-time status. - A trader who is going to execute the transaction needs to see it, and - An auditor needs to monitor all trades currently in the system. Imagine also you want them to use three seperate webapps (or non-servlet applications) to do their work. While not the only approach, it is possible to have all access the same physical Java object. Here are some ways: 1. Implement the Object as an Entity EJB in an EJB container such as JBOSS. Have all the webapps (or whatever) connect to the same EJB Container instance and manipulate the data in the object. The EJB container will manage locking and transactional integrity for you as well. 2. Create the object as a singleton in some JVM somewhere and wrap an RMI server around it. This is basically a hack, but I saw it done once to allow clustered applications to share Properties objects between them (ensuring they were all using the same Properties). (And, yes - it was a pain.) 3. Put the object behind a web service and access it via SOAP. This allows some of the clients to be non-Java. All these solutions are based on putting the object in some place OUTSIDE any of the individual webapps. Joseph Barefoot [EMAIL PROTECTED] on 06/13/2002 02:09:43 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] cc:(bcc: Kevin Bedell/Systems/USHO/SunLife) Subject: RE: Please help clarify or confirm -- HttpSession hmmm...but the sessionIDs have to be unique, even across web apps., correct? 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. 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. Am I missing something here? (besides why the hell you would want to do this) :) joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 10:46 AM To: Struts Users Mailing List Subject: RE: Please help clarify or confirm -- HttpSession In general, there is no way session info from one webapp can be made visible to other webapps. Some details of this may vary depending on your app server. Sessions are controlled by cookies being set on the client. The cookies that are set by each webapp are scoped for that webapp only. As an example, create the following .jsp file and name it session.jsp. Put it in webapp1 html head titleTesting Session Management/title /head body % out.print(Session ID = + request.getSession().getId() ); % /body /html Then, if you were to do a low-level http request from the server, you'd see something like: bash-2.05$ ./telnet -E localhost 8080 [ -- I type
RE: Please help clarify or confirm -- HttpSession
Thanks for all the reply and discussion on the question I asked. I am very interested in doing some proof-of-concept work by sharing the ClassLoader on two web apps. Can someone show me some sample code on how to specify a common class loader for two different web apps? I am running WebLogic 6.1. Thanks... -Original Message- From: Joseph Barefoot [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 2:50 PM To: Struts Users Mailing List Subject: RE: Please help clarify or confirm -- HttpSession The container makes sure that Session ID's are unique. It sets the cookie as well - nothing in the webapp has to do this. This is just how the containers work. Of course. Regarding storing objects from webapp A in a shared classloader class keyed by the sessionID and retrieve them from webapp B. First, you can't physically store an object in another webapp because the memory spaces are isolated from each other. Second, having common directories on the two CLASSPATHS for the two webapps allows you to load CLASSES to create new objects, but not to share the objects once they are created. True, but not what I suggested at all. Two webapps sharing a common CLASSPATH is far different from them having access to a common (shared,parent) CLASSLOADER. In the former two different classloaders are loading the same class into two different memory spaces, as you say. In the latter, a parent classloader is loading a class into a memory space accessible by either of the two child classloaders for the webapps. So I fail to see why a static class with static resources loaded by this parent classloader will not enable objects to be shared between the two child classloaders, so long as the objects themselves are also created from classes loaded by the shared classloader. Note that I am also not claiming that this will 100% work, I just don't see why it wouldn't. But there are ways to share objects (in addition to classes) between webapps. And at times there may be good reasons to do so. For example, imagine you have an object representing a transaction to be executed on your system (maybe a stock trade). What if: - The user who entered the transaction wants to see its real-time status. - A trader who is going to execute the transaction needs to see it, and - An auditor needs to monitor all trades currently in the system. Imagine also you want them to use three seperate webapps (or non-servlet applications) to do their work. While not the only approach, it is possible to have all access the same physical Java object. Here are some ways: 1. Implement the Object as an Entity EJB in an EJB container such as JBOSS. Have all the webapps (or whatever) connect to the same EJB Container instance and manipulate the data in the object. The EJB container will manage locking and transactional integrity for you as well. 2. Create the object as a singleton in some JVM somewhere and wrap an RMI server around it. This is basically a hack, but I saw it done once to allow clustered applications to share Properties objects between them (ensuring they were all using the same Properties). (And, yes - it was a pain.) 3. Put the object behind a web service and access it via SOAP. This allows some of the clients to be non-Java. All these solutions are based on putting the object in some place OUTSIDE any of the individual webapps. Putting an object into a shared classloader DOES put it OUTSIDE of any of the individual webapps, in that that object's existence is not dependent on the existence of any webapp. If this were not true, then the classloader hierarchy employed by app. servers would be meaningless. peace, joe Joseph Barefoot [EMAIL PROTECTED] on 06/13/2002 02:09:43 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] cc:(bcc: Kevin Bedell/Systems/USHO/SunLife) Subject: RE: Please help clarify or confirm -- HttpSession hmmm...but the sessionIDs have to be unique, even across web apps., correct? 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. 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. Am I missing something here? (besides why the hell you would want to do this) :) joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 10:46 AM To: Struts Users Mailing List Subject: RE: Please help clarify or confirm -- HttpSession In general, there is no way session info from one webapp can be made visible to other webapps. Some details of this may vary depending on your app server. Sessions are controlled by cookies being set on the client. The cookies that are set by each
RE: Please help clarify or confirm -- HttpSession
Second, having common directories on the two CLASSPATHS for the two webapps allows you to load CLASSES to create new objects, but not to share the objects once they are created. True, but not what I suggested at all. Two webapps sharing a common CLASSPATH is far different from them having access to a common (shared,parent) CLASSLOADER. In the former two different classloaders are loading the same class into two different memory spaces, as you say. In the latter, a parent classloader is loading a class into a memory space accessible by either of the two child classloaders for the webapps. So I fail to see why a static class with static resources loaded by this parent classloader will not enable objects to be shared between the two child classloaders, so long as the objects themselves are also created from classes loaded by the shared classloader. Note that I am also not claiming that this will 100% work, I just don't see why it wouldn't. Sorry, misunderstood you. I'm not sure if this would work either, but I follow your logic. Seems like it would be easy to try. Just create a simple static class holding a counter and then hit two diff web apps that increment and display its value. Looking at: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html it looks as it the Classloader Hierarchy in Tomcat 4.1 (per the Servlet Spec 2.3 sections 9.4 9.6) provides exactly this functionality. It even says that the shared class loader exists for classes and resources that you wish to share across ALL web applications. So as long as you've got a 2.3 compliant container and you can get the functionality you need from a static class, then this should work. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Please help clarify or confirm -- HttpSession
Damn, not yet ready to go to Tomcat 4.x. Might be a good argument to start moving that direction. (:-) Thanks to everyone for their comments - it's given me plenty to think about. Jerry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 2:00 PM To: Struts Users Mailing List Subject: RE: Please help clarify or confirm -- HttpSession Second, having common directories on the two CLASSPATHS for the two webapps allows you to load CLASSES to create new objects, but not to share the objects once they are created. True, but not what I suggested at all. Two webapps sharing a common CLASSPATH is far different from them having access to a common (shared,parent) CLASSLOADER. In the former two different classloaders are loading the same class into two different memory spaces, as you say. In the latter, a parent classloader is loading a class into a memory space accessible by either of the two child classloaders for the webapps. So I fail to see why a static class with static resources loaded by this parent classloader will not enable objects to be shared between the two child classloaders, so long as the objects themselves are also created from classes loaded by the shared classloader. Note that I am also not claiming that this will 100% work, I just don't see why it wouldn't. Sorry, misunderstood you. I'm not sure if this would work either, but I follow your logic. Seems like it would be easy to try. Just create a simple static class holding a counter and then hit two diff web apps that increment and display its value. Looking at: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html it looks as it the Classloader Hierarchy in Tomcat 4.1 (per the Servlet Spec 2.3 sections 9.4 9.6) provides exactly this functionality. It even says that the shared class loader exists for classes and resources that you wish to share across ALL web applications. So as long as you've got a 2.3 compliant container and you can get the functionality you need from a static class, then this should work. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] This transmission (and any information attached to it) may be confidential and is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient or the person responsible for delivering the transmission to the intended recipient, be advised that you have received this transmission in error and that any use, dissemination, forwarding, printing, or copying of this information is strictly prohibited. If you have received this transmission in error, please immediately notify LabOne at (800)388-4675. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Please help clarify or confirm -- HttpSession
Kevin wrote: It even says that the shared class loader exists for classes and resources that you wish to share across ALL web applications. So as long as you've got a 2.3 compliant container and you can get the functionality you need from a static class, then this should work. Thanks for the support Kevin, I was beginning to wonder if everyone thought I was wacko for suggesting this. :) I do realize that this isn't the most robust or generic solution in the world, but it damn sure would be easy to implement. Jerry (or anyone else interested): If you do test this out, could you please post your conclusions back to the list? This has been a very interesting thread for me (having dealt with classloader craziness in the past), so I'm curious if theory is backed by reality in this case. peace, Joe Barefoot -Original Message- From: Jerry Jalenak [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 12:17 PM To: 'Struts Users Mailing List' Subject: RE: Please help clarify or confirm -- HttpSession Damn, not yet ready to go to Tomcat 4.x. Might be a good argument to start moving that direction. (:-) Thanks to everyone for their comments - it's given me plenty to think about. Jerry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 2:00 PM To: Struts Users Mailing List Subject: RE: Please help clarify or confirm -- HttpSession Second, having common directories on the two CLASSPATHS for the two webapps allows you to load CLASSES to create new objects, but not to share the objects once they are created. True, but not what I suggested at all. Two webapps sharing a common CLASSPATH is far different from them having access to a common (shared,parent) CLASSLOADER. In the former two different classloaders are loading the same class into two different memory spaces, as you say. In the latter, a parent classloader is loading a class into a memory space accessible by either of the two child classloaders for the webapps. So I fail to see why a static class with static resources loaded by this parent classloader will not enable objects to be shared between the two child classloaders, so long as the objects themselves are also created from classes loaded by the shared classloader. Note that I am also not claiming that this will 100% work, I just don't see why it wouldn't. Sorry, misunderstood you. I'm not sure if this would work either, but I follow your logic. Seems like it would be easy to try. Just create a simple static class holding a counter and then hit two diff web apps that increment and display its value. Looking at: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html it looks as it the Classloader Hierarchy in Tomcat 4.1 (per the Servlet Spec 2.3 sections 9.4 9.6) provides exactly this functionality. It even says that the shared class loader exists for classes and resources that you wish to share across ALL web applications. So as long as you've got a 2.3 compliant container and you can get the functionality you need from a static class, then this should work. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] This transmission (and any information attached to it) may be confidential and is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient or the person responsible for delivering the transmission to the intended recipient, be advised that you have received this transmission in error and that any use, dissemination, forwarding, printing, or copying of this information is strictly prohibited. If you have received this transmission in error, please immediately notify LabOne at (800)388-4675. -- 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]
RE: Please help clarify or confirm -- HttpSession
I've got the framework and initial application to complete and demo before next Wednesday, so I'm a little tight on time. Hopefully around the first of the July I'll some time to play around with this. In the meantime if anyone else can give it a go, please be sure to let everyone know. Thanks. Jerry -Original Message- From: Joseph Barefoot [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 2:28 PM To: Struts Users Mailing List Subject: RE: Please help clarify or confirm -- HttpSession Kevin wrote: It even says that the shared class loader exists for classes and resources that you wish to share across ALL web applications. So as long as you've got a 2.3 compliant container and you can get the functionality you need from a static class, then this should work. Thanks for the support Kevin, I was beginning to wonder if everyone thought I was wacko for suggesting this. :) I do realize that this isn't the most robust or generic solution in the world, but it damn sure would be easy to implement. Jerry (or anyone else interested): If you do test this out, could you please post your conclusions back to the list? This has been a very interesting thread for me (having dealt with classloader craziness in the past), so I'm curious if theory is backed by reality in this case. peace, Joe Barefoot -Original Message- From: Jerry Jalenak [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 12:17 PM To: 'Struts Users Mailing List' Subject: RE: Please help clarify or confirm -- HttpSession Damn, not yet ready to go to Tomcat 4.x. Might be a good argument to start moving that direction. (:-) Thanks to everyone for their comments - it's given me plenty to think about. Jerry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 2:00 PM To: Struts Users Mailing List Subject: RE: Please help clarify or confirm -- HttpSession Second, having common directories on the two CLASSPATHS for the two webapps allows you to load CLASSES to create new objects, but not to share the objects once they are created. True, but not what I suggested at all. Two webapps sharing a common CLASSPATH is far different from them having access to a common (shared,parent) CLASSLOADER. In the former two different classloaders are loading the same class into two different memory spaces, as you say. In the latter, a parent classloader is loading a class into a memory space accessible by either of the two child classloaders for the webapps. So I fail to see why a static class with static resources loaded by this parent classloader will not enable objects to be shared between the two child classloaders, so long as the objects themselves are also created from classes loaded by the shared classloader. Note that I am also not claiming that this will 100% work, I just don't see why it wouldn't. Sorry, misunderstood you. I'm not sure if this would work either, but I follow your logic. Seems like it would be easy to try. Just create a simple static class holding a counter and then hit two diff web apps that increment and display its value. Looking at: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html it looks as it the Classloader Hierarchy in Tomcat 4.1 (per the Servlet Spec 2.3 sections 9.4 9.6) provides exactly this functionality. It even says that the shared class loader exists for classes and resources that you wish to share across ALL web applications. So as long as you've got a 2.3 compliant container and you can get the functionality you need from a static class, then this should work. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] This transmission (and any information attached to it) may be confidential and is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient or the person responsible for delivering the transmission to the intended recipient, be advised that you have received this transmission in error and that any use, dissemination, forwarding, printing, or copying of this information is strictly prohibited. If you have received this transmission in error, please immediately notify LabOne at (800)388-4675. -- 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] This transmission (and any information attached to it) may be confidential and is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient or the person responsible for delivering the transmission to the intended recipient, be advised that you have received this transmission in error
RE: Please help clarify or confirm -- HttpSession
Cool. Building on this then, I should be able to define some sort of
Collection (HashMap? Vector?) that I should be able to store instances of a
bean into (i.e. my authenticated user bean). It looks like everything needs
to be defined as static - no problem. What about synchronization problems?
Does the access need to be serialized in anyway?
Jerry
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 13, 2002 3:04 PM
To: Struts Users Mailing List
Subject: RE: Please help clarify or confirm -- HttpSession
OK. I checked this out.
I'm running Tomcat 4.03 on NT with JDK 1.3.1.
I created a simple static class:
-
public class ClassLoaderTest {
public static int counter;
public static void addCounter() {
counter++;
}
public static String getCounter () {
return Integer.toString(counter);
}
}
I compiled it and put the .class file in %CATALINA_HOME%\classes
-
I then created a simple jsp named test.jsp
%@ page import=ClassLoaderTest %
html
head
titleTesting Class Loaders/title
/head
body
% ClassLoaderTest.addCounter(); %
% out.print(Counter = + ClassLoaderTest.getCounter() ); %
/body
/html
-
I then created two webapps, webapp1 and webapp2. They are completely
empty except for the test.jsp file and the following web.xml file:
?xml version=1.0 encoding=ISO-8859-1?
!DOCTYPE web-app
PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN
http://java.sun.com/j2ee/dtds/web-app_2_2.dtd;
web-app
!-- The Usual Welcome File List --
welcome-file-list
welcome-fileindex.jsp/welcome-file
/welcome-file-list
/web-app
Now - I then restarted Tomcat and opened two browsers. I pointed one to:
http://localhost:8080/webapp1/test.jsp
and the other to:
http://localhost:8080/webapp2/test.jsp
Then when I hit refresh on them I can see THEY ARE HITTING THE SAME OBJECT.
That is, this works. The counter increments each time I refresh either
browser.
Thanks for the thoughts on this Joe -
Kevin
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
This transmission (and any information attached to it) may be confidential and is
intended solely for the use of the individual or entity to which it is addressed. If
you are not the intended recipient or the person responsible for delivering the
transmission to the intended recipient, be advised that you have received this
transmission in error and that any use, dissemination, forwarding, printing, or
copying of this information is strictly prohibited. If you have received this
transmission in error, please immediately notify LabOne at (800)388-4675.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Please help clarify or confirm -- HttpSession
Not sure about these - maybe someone else can grab the ball and push ahead.
One of the things I was wondering about were FormBean instances and other
complex objects such as DB Pool connections.
Jerry Jalenak [EMAIL PROTECTED] on 06/13/2002 04:38:28 PM
Please respond to Struts Users Mailing List
[EMAIL PROTECTED]
To: 'Struts Users Mailing List' [EMAIL PROTECTED]
cc:(bcc: Kevin Bedell/Systems/USHO/SunLife)
Subject: RE: Please help clarify or confirm -- HttpSession
Cool. Building on this then, I should be able to define some sort of
Collection (HashMap? Vector?) that I should be able to store instances of a
bean into (i.e. my authenticated user bean). It looks like everything
needs
to be defined as static - no problem. What about synchronization problems?
Does the access need to be serialized in anyway?
Jerry
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 13, 2002 3:04 PM
To: Struts Users Mailing List
Subject: RE: Please help clarify or confirm -- HttpSession
OK. I checked this out.
I'm running Tomcat 4.03 on NT with JDK 1.3.1.
I created a simple static class:
-
public class ClassLoaderTest {
public static int counter;
public static void addCounter() {
counter++;
}
public static String getCounter () {
return Integer.toString(counter);
}
}
I compiled it and put the .class file in %CATALINA_HOME%\classes
-
I then created a simple jsp named test.jsp
%@ page import=ClassLoaderTest %
html
head
titleTesting Class Loaders/title
/head
body
% ClassLoaderTest.addCounter(); %
% out.print(Counter = + ClassLoaderTest.getCounter() ); %
/body
/html
-
I then created two webapps, webapp1 and webapp2. They are completely
empty except for the test.jsp file and the following web.xml file:
?xml version=1.0 encoding=ISO-8859-1?
!DOCTYPE web-app
PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN
http://java.sun.com/j2ee/dtds/web-app_2_2.dtd;
web-app
!-- The Usual Welcome File List --
welcome-file-list
welcome-fileindex.jsp/welcome-file
/welcome-file-list
/web-app
Now - I then restarted Tomcat and opened two browsers. I pointed one to:
http://localhost:8080/webapp1/test.jsp
and the other to:
http://localhost:8080/webapp2/test.jsp
Then when I hit refresh on them I can see THEY ARE HITTING THE SAME OBJECT.
That is, this works. The counter increments each time I refresh either
browser.
Thanks for the thoughts on this Joe -
Kevin
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
This transmission (and any information attached to it) may be confidential
and is intended solely for the use of the individual or entity to which it
is addressed. If you are not the intended recipient or the person
responsible for delivering the transmission to the intended recipient, be
advised that you have received this transmission in error and that any use,
dissemination, forwarding, printing, or copying of this information is
strictly prohibited. If you have received this transmission in error,
please immediately notify LabOne at (800)388-4675.
--
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]
RE: Please help clarify or confirm -- HttpSession
Although I don't recommend using ASP with Java, it is possible. http://support.microsoft.com/default.aspx?scid=kb;EN-US;q167941 I have more experience with this then I care to admit. HTH! James Mitchell Software Engineer\Struts Evangelist Struts-Atlanta, the Open Minded Developer Network http://struts-atlanta.open-tools.org -Original Message- From: Jerry Jalenak [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 2:12 PM To: 'Struts Users Mailing List'; '[EMAIL PROTECTED]' Subject: RE: Please help clarify or confirm -- HttpSession A couple of reasons 1. My company has three main lines of business that for various regulatory reasons need to be kept separate. This applies to deliver of content on the web as well. What I am trying to accomplish is essentially a single-signon capability (within the framework) that the business applications can then validate against (successful logon, etc.). 2. I am also needing to integrate non-JSP applications (.ASP for instance) into the framework. I know they cannot directly access my JavaBeans, but I'm wondering if a .ASP page could access the HttpSession data. Jerry -Original Message- From: Joseph Barefoot [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 1:10 PM To: Struts Users Mailing List Subject: RE: Please help clarify or confirm -- HttpSession hmmm...but the sessionIDs have to be unique, even across web apps., correct? 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. 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. Am I missing something here? (besides why the hell you would want to do this) :) joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 10:46 AM To: Struts Users Mailing List Subject: RE: Please help clarify or confirm -- HttpSession In general, there is no way session info from one webapp can be made visible to other webapps. Some details of this may vary depending on your app server. Sessions are controlled by cookies being set on the client. The cookies that are set by each webapp are scoped for that webapp only. As an example, create the following .jsp file and name it session.jsp. Put it in webapp1 html head titleTesting Session Management/title /head body % out.print(Session ID = + request.getSession().getId() ); % /body /html Then, if you were to do a low-level http request from the server, you'd see something like: bash-2.05$ ./telnet -E localhost 8080 [ -- I type ] Trying 127.0.0.1... Connected to localhost. Escape character is 'off'. GET /webapp1/session.jsp HTTP/1.0 [ -- I type ] HTTP/1.1 200 OK Content-Type: text/html;charset=ISO-8859-1 Date: Wed, 12 Jun 2002 00:39:49 GMT Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector) Connection: close Set-Cookie: JSESSIONID=AC75B22FD1D283D1CEF0136928110679;Path=/webapp1 html head titleTesting Session Management/title /head body Session ID = AC75B22FD1D283D1CEF0136928110679 /body /html Connection closed by foreign host. bash-2.05$ The JSESSIONID cookie is used by the servlet container to manage the user session. Notice that the the scope of the JSESSIONID Cookie in this example is limited to the '/webapp1' web application. So even if you have many web applications (or Struts applications) deployed in a servlet container, session tracking is isolated between them. ShamelessPlug I'll be covering topics such as this and others in my upcoming book Struts: Rapid Working Knowledge to be published by SAMS later this year. /ShamelessPlug HTH, Kevin Jerry Jalenak [EMAIL PROTECTED] on 06/13/2002 01:43:50 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] cc:(bcc: Kevin Bedell/Systems/USHO/SunLife) Subject: RE: Please help clarify or confirm -- HttpSession This is something I've wondered about, especially in a team development environment where there are several programmers working on different webapps that need to share a common framework - in other words, something like this: Tomcat\webapps framework-application WEB-INF ... webapplication_1 WEB-INF ... webapplication_2 WEB-INF ... etc etc etc Can the classes in webapplication_1 'see' session data that was created and stored in the session by the framework-application? Jerry -Original Message- From: emmanuel.boudrant [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 12:39 PM To: Struts
RE: Please help clarify or confirm -- HttpSession
Thanks for confirming this Kevin. Should work for sharing object instances
just fine based on your test.
Jerry:
I would recommend using a java.util.Hashtable, and storing your
authenticated user bean with a String containing the jsessionid. This
should be safe.
peace,
Joe
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 13, 2002 1:28 PM
To: Struts Users Mailing List
Subject: RE: Please help clarify or confirm -- HttpSession
Not sure about these - maybe someone else can grab the ball and
push ahead.
One of the things I was wondering about were FormBean instances and other
complex objects such as DB Pool connections.
Jerry Jalenak [EMAIL PROTECTED] on 06/13/2002 04:38:28 PM
Please respond to Struts Users Mailing List
[EMAIL PROTECTED]
To: 'Struts Users Mailing List' [EMAIL PROTECTED]
cc:(bcc: Kevin Bedell/Systems/USHO/SunLife)
Subject: RE: Please help clarify or confirm -- HttpSession
Cool. Building on this then, I should be able to define some sort of
Collection (HashMap? Vector?) that I should be able to store
instances of a
bean into (i.e. my authenticated user bean). It looks like everything
needs
to be defined as static - no problem. What about synchronization
problems?
Does the access need to be serialized in anyway?
Jerry
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 13, 2002 3:04 PM
To: Struts Users Mailing List
Subject: RE: Please help clarify or confirm -- HttpSession
OK. I checked this out.
I'm running Tomcat 4.03 on NT with JDK 1.3.1.
I created a simple static class:
-
public class ClassLoaderTest {
public static int counter;
public static void addCounter() {
counter++;
}
public static String getCounter () {
return Integer.toString(counter);
}
}
I compiled it and put the .class file in %CATALINA_HOME%\classes
-
I then created a simple jsp named test.jsp
%@ page import=ClassLoaderTest %
html
head
titleTesting Class Loaders/title
/head
body
% ClassLoaderTest.addCounter(); %
% out.print(Counter = + ClassLoaderTest.getCounter() ); %
/body
/html
-
I then created two webapps, webapp1 and webapp2. They are completely
empty except for the test.jsp file and the following web.xml file:
?xml version=1.0 encoding=ISO-8859-1?
!DOCTYPE web-app
PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN
http://java.sun.com/j2ee/dtds/web-app_2_2.dtd;
web-app
!-- The Usual Welcome File List --
welcome-file-list
welcome-fileindex.jsp/welcome-file
/welcome-file-list
/web-app
Now - I then restarted Tomcat and opened two browsers. I pointed one to:
http://localhost:8080/webapp1/test.jsp
and the other to:
http://localhost:8080/webapp2/test.jsp
Then when I hit refresh on them I can see THEY ARE HITTING THE
SAME OBJECT.
That is, this works. The counter increments each time I refresh either
browser.
Thanks for the thoughts on this Joe -
Kevin
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
This transmission (and any information attached to it) may be confidential
and is intended solely for the use of the individual or entity to which it
is addressed. If you are not the intended recipient or the person
responsible for delivering the transmission to the intended recipient, be
advised that you have received this transmission in error and
that any use,
dissemination, forwarding, printing, or copying of this information is
strictly prohibited. If you have received this transmission in error,
please immediately notify LabOne at (800)388-4675.
--
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]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Please help clarify or confirm -- HttpSession
Oops, forgot to clarify Jerry:
Any access to a java.util.Hashtable is synchronized, so using it as a static
repository for shared in-memory data should be safe and fast. Also, the
class definition for any objects that are stored in this Hashtable should be
loaded from the same (shared) classloader as the class containing the
hashtable itself. So the utility class plus shared object classes should be
contained in the same JAR and dropped in the shared library folder (or
whatever you have to do to get the container to load this classes as
shared).
peace,
Joe
-Original Message-
From: Joseph Barefoot [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 13, 2002 2:11 PM
To: Struts Users Mailing List
Subject: RE: Please help clarify or confirm -- HttpSession
Thanks for confirming this Kevin. Should work for sharing object
instances
just fine based on your test.
Jerry:
I would recommend using a java.util.Hashtable, and storing your
authenticated user bean with a String containing the jsessionid. This
should be safe.
peace,
Joe
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 13, 2002 1:28 PM
To: Struts Users Mailing List
Subject: RE: Please help clarify or confirm -- HttpSession
Not sure about these - maybe someone else can grab the ball and
push ahead.
One of the things I was wondering about were FormBean instances
and other
complex objects such as DB Pool connections.
Jerry Jalenak [EMAIL PROTECTED] on 06/13/2002 04:38:28 PM
Please respond to Struts Users Mailing List
[EMAIL PROTECTED]
To: 'Struts Users Mailing List' [EMAIL PROTECTED]
cc:(bcc: Kevin Bedell/Systems/USHO/SunLife)
Subject: RE: Please help clarify or confirm -- HttpSession
Cool. Building on this then, I should be able to define some sort of
Collection (HashMap? Vector?) that I should be able to store
instances of a
bean into (i.e. my authenticated user bean). It looks like everything
needs
to be defined as static - no problem. What about synchronization
problems?
Does the access need to be serialized in anyway?
Jerry
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 13, 2002 3:04 PM
To: Struts Users Mailing List
Subject: RE: Please help clarify or confirm -- HttpSession
OK. I checked this out.
I'm running Tomcat 4.03 on NT with JDK 1.3.1.
I created a simple static class:
-
public class ClassLoaderTest {
public static int counter;
public static void addCounter() {
counter++;
}
public static String getCounter () {
return Integer.toString(counter);
}
}
I compiled it and put the .class file in %CATALINA_HOME%\classes
-
I then created a simple jsp named test.jsp
%@ page import=ClassLoaderTest %
html
head
titleTesting Class Loaders/title
/head
body
% ClassLoaderTest.addCounter(); %
% out.print(Counter = + ClassLoaderTest.getCounter() ); %
/body
/html
-
I then created two webapps, webapp1 and webapp2. They are
completely
empty except for the test.jsp file and the following web.xml file:
?xml version=1.0 encoding=ISO-8859-1?
!DOCTYPE web-app
PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN
http://java.sun.com/j2ee/dtds/web-app_2_2.dtd;
web-app
!-- The Usual Welcome File List --
welcome-file-list
welcome-fileindex.jsp/welcome-file
/welcome-file-list
/web-app
Now - I then restarted Tomcat and opened two browsers. I pointed one to:
http://localhost:8080/webapp1/test.jsp
and the other to:
http://localhost:8080/webapp2/test.jsp
Then when I hit refresh on them I can see THEY ARE HITTING THE
SAME OBJECT.
That is, this works. The counter increments each time I refresh either
browser.
Thanks for the thoughts on this Joe -
Kevin
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
This transmission (and any information attached to it) may be
confidential
and is intended solely for the use of the individual or entity
to which it
is addressed. If you are not the intended recipient or the person
responsible for delivering the transmission to the intended
recipient, be
advised that you have received this transmission in error and
that any use,
dissemination, forwarding, printing, or copying of this information is
strictly prohibited. If you have received this transmission in error,
please immediately notify LabOne at (800)388-4675.
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL
RE: Please help clarify or confirm -- HttpSession
I haven't noticed anyone else pointing this out yet, so I guess maybe I
should... The approach described below (as far as I can see) will only work
if you assume your app will never be deployed on more than a single server -
or if you are fine with the fact that this 'shared' object will not actually
be shared across multiple server instances in the cluster.
If you can be certain you will never need to scale your apps to more than
one server this may be appropriate, but personally I would be very leary
about relying on this for any real project... YMMV
Ralph Roland
Strata-J
[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 13, 2002 4:04 PM
To: Struts Users Mailing List
Subject: RE: Please help clarify or confirm -- HttpSession
OK. I checked this out.
I'm running Tomcat 4.03 on NT with JDK 1.3.1.
I created a simple static class:
-
public class ClassLoaderTest {
public static int counter;
public static void addCounter() {
counter++;
}
public static String getCounter () {
return Integer.toString(counter);
}
}
I compiled it and put the .class file in %CATALINA_HOME%\classes
-
I then created a simple jsp named test.jsp
%@ page import=ClassLoaderTest %
html
head
titleTesting Class Loaders/title
/head
body
% ClassLoaderTest.addCounter(); %
% out.print(Counter = + ClassLoaderTest.getCounter() ); %
/body
/html
-
I then created two webapps, webapp1 and webapp2. They are
completely empty except for the test.jsp file and the following
web.xml file:
?xml version=1.0 encoding=ISO-8859-1?
!DOCTYPE web-app
PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN
http://java.sun.com/j2ee/dtds/web-app_2_2.dtd;
web-app
!-- The Usual Welcome File List --
welcome-file-list
welcome-fileindex.jsp/welcome-file
/welcome-file-list
/web-app
Now - I then restarted Tomcat and opened two browsers. I pointed one to:
http://localhost:8080/webapp1/test.jsp
and the other to:
http://localhost:8080/webapp2/test.jsp
Then when I hit refresh on them I can see THEY ARE HITTING THE
SAME OBJECT. That is, this works. The counter increments each
time I refresh either
browser.
Thanks for the thoughts on this Joe -
Kevin
--
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]
RE: Please help clarify or confirm -- HttpSession
Agreed. The shared classloader approach is a fast-and-dirty solution that
would have to be replaced in a clustered environment.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 13, 2002 2:26 PM
To: Struts Users Mailing List
Subject: RE: Please help clarify or confirm -- HttpSession
Ralph -
I agree - In one of my first responses I recommended using an ejb server
for this - that way you can have multiple servers accessing it at the same
time while having the ejb server managing locking and transactions if
required.
Ralph Roland [EMAIL PROTECTED] on 06/13/2002 05:44:41 PM
Please respond to Struts Users Mailing List
[EMAIL PROTECTED]
To: Struts Users Mailing List [EMAIL PROTECTED]
cc:(bcc: Kevin Bedell/Systems/USHO/SunLife)
Subject: RE: Please help clarify or confirm -- HttpSession
I haven't noticed anyone else pointing this out yet, so I guess maybe I
should... The approach described below (as far as I can see) will only
work
if you assume your app will never be deployed on more than a single server
-
or if you are fine with the fact that this 'shared' object will not
actually
be shared across multiple server instances in the cluster.
If you can be certain you will never need to scale your apps to more than
one server this may be appropriate, but personally I would be very leary
about relying on this for any real project... YMMV
Ralph Roland
Strata-J
[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 13, 2002 4:04 PM
To: Struts Users Mailing List
Subject: RE: Please help clarify or confirm -- HttpSession
OK. I checked this out.
I'm running Tomcat 4.03 on NT with JDK 1.3.1.
I created a simple static class:
-
public class ClassLoaderTest {
public static int counter;
public static void addCounter() {
counter++;
}
public static String getCounter () {
return Integer.toString(counter);
}
}
I compiled it and put the .class file in %CATALINA_HOME%\classes
-
I then created a simple jsp named test.jsp
%@ page import=ClassLoaderTest %
html
head
titleTesting Class Loaders/title
/head
body
% ClassLoaderTest.addCounter(); %
% out.print(Counter = + ClassLoaderTest.getCounter() ); %
/body
/html
-
I then created two webapps, webapp1 and webapp2. They are
completely empty except for the test.jsp file and the following
web.xml file:
?xml version=1.0 encoding=ISO-8859-1?
!DOCTYPE web-app
PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN
http://java.sun.com/j2ee/dtds/web-app_2_2.dtd;
web-app
!-- The Usual Welcome File List --
welcome-file-list
welcome-fileindex.jsp/welcome-file
/welcome-file-list
/web-app
Now - I then restarted Tomcat and opened two browsers. I pointed one to:
http://localhost:8080/webapp1/test.jsp
and the other to:
http://localhost:8080/webapp2/test.jsp
Then when I hit refresh on them I can see THEY ARE HITTING THE
SAME OBJECT. That is, this works. The counter increments each
time I refresh either
browser.
Thanks for the thoughts on this Joe -
Kevin
--
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]
--
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]
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]
RE: Please help clarify or confirm -- HttpSession
On Thu, 13 Jun 2002, Jerry Jalenak wrote: Date: Thu, 13 Jun 2002 13:12:00 -0500 From: Jerry Jalenak [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED], '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: RE: Please help clarify or confirm -- HttpSession A couple of reasons 1. My company has three main lines of business that for various regulatory reasons need to be kept separate. This applies to deliver of content on the web as well. What I am trying to accomplish is essentially a single-signon capability (within the framework) that the business applications can then validate against (successful logon, etc.). Single sign on is a different kettle of fish ... and it does *not* require sharing sessions for the server to accomodate it. Tomcat 4, for example, supports single sign on -- see the server config documents on the Host element of server.xml for the details. All this does for you, though, is avoid the need for a user to log in to each app -- it does nothing for sharing information between apps. Your best bet is to do something like: * Store the shared info in a database or EJB that is accessible to all the relevant webapps. * Store shared information in a static variable associated with a class that is loaded from the shared class loader (so that there really is only one instance). Figuring out how to relate the information from various webapps together is an exercise left to the user, but you can probably do something with the fact that request.getRemoteUser() will return the same value in every webapp. 2. I am also needing to integrate non-JSP applications (.ASP for instance) into the framework. I know they cannot directly access my JavaBeans, but I'm wondering if a .ASP page could access the HttpSession data. I don't have a clue how you could possibly accomplish this, given that the ASP pages aren't running inside the same JVM that Tomcat is. Jerry Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
