See comments below.
Sreekumar Pillai wrote:
> In the following example,
>
> class ConnectionManager
> {
> ..
> private ConnectionManager(){
> }
> static private ConnectionManager a_instance = null;
>
> synchronized static public ConnectionManager instance()
> {
> if (a_instance == null) a_instance = new ConnectionManager();
> return a_instance;
> }
> ...
> }
>
> 1. Application 1 - JSPPage1
>
> ....
> <! ConnectionManager aConnectionManager =
> ConnectionManager.instance();
> ...
>
> 2. Application 1 on webserver1- JSPPage2
>
> ....
> <! ConnectionManager aConnectionManager =
> ConnectionManager.instance();
> ...
>
> 3. Application 2 on webserver1 - JSPPage2
>
> ....
> <! ConnectionManager aConnectionManager =
> ConnectionManager.instance();
> ...
>
> 1. If I understand the concepts correctly, in all the above cases, we should
> get the same instance of the ConnectionManager object. Or am I missing
> something? (ConnectionManager class is in the CLASSPATH of the webserver ).
>
In all servlet containers, case 1 and case 2 (where both pages are in the same
application) you will get the same instance. For case 3 (a separate application on
the same web server), the answer depends on which servlet container, and how you've
got it configured.
The issue that causes the complexity is that "static" classes and objects are only
shared by classes loaded by the same Java class loader (even if they have the same
name). For most Java applications this subtlety is not visible, because only one
class loader is normally used.
Some servlet containers support auto-reloading on changes to servlet class files.
In such cases, they typically use a different class loader per application, because
the only way to implement class reloading in Java is to throw away a class loader
(and all the classes loaded by it). In such cases, you can typically configure
classes to be loaded from the system class path, so they are shared, or the
application-specific class path so they are not.
To take a concrete example, lets assume you are running Apache JServ (which
supports class reloading). If you configure your ConnectionManager class on the
system class path, both apps will share the same connection. However, if you've
got ConnectionManager visible through the "repositories" lists for the two apps, it
will not be shared, because each app is loaded by a separate class loader.
> 2. What is the recommended way of doing this?
See following answer.
>
> 3. I can put the ConnectionManager in ServletContext() and initialize using
> a dummy servlet. What is the difference in this approach?
The difference is that your ConnectionManager instance is guaranteed to be visible
to only the application you initialize it from, because servlet context attributes
are not shared across applications (even if everything is loaded by the same class
loader). For this reason, I normally use this approach -- I don't like the
possibility of accidental sharing of my global variables between applications that
just happen to be running on the same server. There is too much chance of
applications interfering with each other just because I installed them together.
>
> 4. Is there any other way of sharing global data objects?
In Java, you ultimately need to use a static variable or acquire a reference to an
instance somehow. The only question should be "how much visibility do I really
want to have."
>
> 5. What is the recommended procedure in an OO world?
>
Singletons (as you illustrated above) are pretty much the classic OO approach.
However, the servlet world requires you to think about degrees of global-ness,
instead of it being all or nothing. When you are sharing your server's JVM, with
apps you might or might not know about ahead of time, you need to think about that.
>
> Thanks in advance
> Sree
>
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
