Hi,
You can google for the exact definition of the singleton design pattern.
In this case, you would write a singleton to hold all the beans, one per
user, instead of putting them in the session object.  Because there will
be only one instance of this singleton in the JVM, it will be shared by
the non-SSL and SSL hosts.  Your JSP pages and servlets would get the
user bean from this singleton instead of from the session.

If you need specific code we'll be glad to help.

Yoav Shapira
Millennium Research Informatics


>-----Original Message-----
>From: Charles Daniel [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, March 30, 2004 1:53 PM
>To: Tomcat Users List
>Subject: Re: What's happening to my beans?
>
>Thanks Yoav, I've figured as much.  From my old C programming days I am
>well aware of scoping rules.  Yet I am still at a loss of how to solve
this
>particular problem.  I'm not certain how to using a database would
solve
>the problem and I'm not familiar with singleton. What is it and how can
I
>use it.
>
>Thanks
>
>Charles
>  ----- Original Message -----
>  From: Shapira, Yoav<mailto:[EMAIL PROTECTED]>
>  To: Tomcat Users List<mailto:[EMAIL PROTECTED]>
>  Sent: Tuesday, March 30, 2004 12:41 PM
>  Subject: RE: What's happening to my beans?
>
>
>
>  Hi,
>  I think you can't have the same session for both SSL and non-SSL
>  activity.  You get different sessions, each with its own bean, hence
the
>  behavior you describe.  Can you use a database?  A share singleton?
>
>  Yoav Shapira
>  Millennium Research Informatics
>
>
>  >-----Original Message-----
>  >From: Charles Daniel [mailto:[EMAIL PROTECTED]
>  >Sent: Tuesday, March 30, 2004 1:37 PM
>  >To: [EMAIL PROTECTED]<mailto:tomcat-
>[EMAIL PROTECTED]>
>  >Subject: What's happening to my beans?
>  >
>  >My installation is Apache2+Tomcat4+mod_ssl.  I am running a http
main
>  >server along with a https virtual host on an aliased ip address.  To
>  track
>  >users I created a session bean which holds user info ( e-mail, login
>  status
>  >).  Naturally this bean holds vital information as it allows links
to
>  the
>  >users transactions such as shopping cart transactions.
>  >
>  >The bean is accessible by both servers (same machine and application
>  >directory tree). The SSL enabled virtual host now serves my Login,
>  >Registration and Shopping Cart JSP's while the main server serves
the
>  non-
>  >secure pages.
>  >
>  >Before I implemented SSL the strategy of using a bean to track users
>  was
>  >sound, but now it seems that the bean is not persistant between the
>  main
>  >server and virtual host. My guess is that main server and the
virtual
>  host
>  >have their own version of the bean.  Therefore, the bean in my
virtual
>  host
>  >is out of scope once I navigate back to page controlled by the main
>  server.
>  >The result is that the main server is left unaware if the user has
>  logged
>  >in or whether or not the user has a shopping cart containing items.
>  >
>  >Is there a better strategy for communicating information like this
>  between
>  >the main server and the virtual host. I am reluctant to try using
>  cookies.
>  >
>  >I've tried the java.sun.com JSP forum with no success.  Maybe you
guys
>  can
>  >help even if this post is a little off subject for this forum.
>
>
>
>  This e-mail, including any attachments, is a confidential business
>communication, and may contain information that is confidential,
>proprietary and/or privileged.  This e-mail is intended only for the
>individual(s) to whom it is addressed, and may not be saved, copied,
>printed, disclosed or used by anyone else.  If you are not the(an)
intended
>recipient, please immediately delete this e-mail from your computer
system
>and notify the sender.  Thank you.
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: tomcat-user-
>[EMAIL PROTECTED]<mailto:tomcat-user-
>[EMAIL PROTECTED]>
>  For additional commands, e-mail: tomcat-user-
>[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to