Just don't forged to synchronize the access to the singleton mehtods... in standalone application synchronization is not needed,
but in server side code it is vital.
Singleton is a class that may have zero or one instance only. It is achived with private constructor.


Charles Daniel wrote:

Thanks, I'll try google first to see what it's all about.

Thanks Again,

Charles
----- Original Message ----- From: Shapira, Yoav<mailto:[EMAIL PROTECTED]> To: Tomcat Users List<mailto:[EMAIL PROTECTED]> Sent: Tuesday, March 30, 2004 12:56 PM
Subject: RE: What's happening to my beans?




 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]<mailto:[EMAIL PROTECTED]>> > To: Tomcat Users List<mailto:[EMAIL PROTECTED]<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<mailto:[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<mailto:tomcat-user>- >[EMAIL PROTECTED]> > For additional commands, e-mail: tomcat-user- >[EMAIL PROTECTED]<mailto:[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]<mailto:[EMAIL PROTECTED]> For additional commands, e-mail: [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>






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



Reply via email to