You are 100% correct.

Luckily this approach is actually very simple in implementation, but if
used, the handle to the shared utility object should be provided by a
factory method and the utility object itself should conform to an interface
(in each application).  Calling application objects should use this
interface and factory method to get/store objects.  That way a more robust
implementation can be swapped in "under the covers" without affecting the
calling applications.

A more robust implemenation would be to store the shared session data in a
common database, if the applications are indeed using the same database.
This has its own implications, however...  If they are not using a common
database, then an EJB layer or perhaps XML through sockets or over HTTP
between applications would be required.  I guess you would call the latter a
"web service" (why not). :)

peace,
Joe Barefoot

> -----Original Message-----
> From: Ralph Roland [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 13, 2002 2:45 PM
> To: Struts Users Mailing List
> 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>
> >     <title>Testing 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-file>index.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]>

Reply via email to