I have a class which I put in the servlet directory of the web server (Netscape IPlanet).
Now I have two identical servlets (named differently of course) which access the TestClass class. Both are as follows:
Running the two identical servlets shows that each are in the same context, but each has a different timestamp. I was hoping to get the same timstamp for each, which would show that I am using the same instance of the object in both servlets. Instead it appears that two separate instances of the object are being instantiated. I know that I could effectively share this object by placing it in the ServletContext and accessing it that way, but that's not the point. I am more curious as to WHY there are different instances of the object being created. Anyone have any ideas? Thanks, Jay [This message has been edited by Jason Menard (edited February 20, 2001).] [This message has been edited by Jason Menard (edited February 20, 2001).]
Frank, you're right. That's not the problem in this case though, but I did go ahead and synchronize things. Anyone have any other ideas? I know this almost sounds like a test question but it's actually work related. Thanks, Jay
Joined: Jan 07, 1999
Is it possible that your servlets are loaded by different classloaders or web-apps? "static" members are only shared within the same classloader.
Peter den Haan
Joined: Apr 20, 2000
Originally posted by Frank Carver: Is it possible that your servlets are loaded by different classloaders or web-apps? "static" members are only shared within the same classloader.
Agreed -- sounds like you may be caught out by the classloaders. Especially older servlet engines like to instantiate new classloaders. For example, when a class needs to be re-loaded because you have updated it, the engine may use a fresh classloader to do it. This can also lead to unexpected ClassCastExceptions if you're trying to cast between different loads of classes. The servlet spec has this to say about it: Many servlet containers support servlet reloading for ease of development. Reloading of servlet classes has been accomplished by previous generations of servlet containers by creating a new class loader to load the servlet which is distinct from class loaders used to load other servlets or the classes that they use in the servlet context. This can have the undesirable side effect of causing object references within a servlet context to point at a different class or object than expected which can cause unexpected behavior. Therefore, when a Container Provider implements a class reloading scheme for ease of development, they must ensure that all servlets, and classes that they may use, are loaded in the scope of a single class loader guaranteeing that the application will behave as expected by the Developer. (section 4.6 in version 2.2 of the spec). - Peter
[This message has been edited by Peter den Haan (edited February 22, 2001).]
Joined: Nov 09, 2000
Thanks for the info. I guess it could be a classloader thing. There really is no way to know for sure is there? The web server btw is the latest version of Netscape IPlanet, if tha tmeans anything. What I'm going to end up doing is make a servlet that instantiates the class and puts it into the ServletContext. This servlet will be run at server startup. Then all servers sharing that context will be able to access that same instance of the class. Thanks for the replies. Jay
Joined: Oct 12, 2000
It's not a classloader thing. The simplest explanation is that you are creating a new TestClass tc on every request and since you are not holding any reference to it, it's being garbage collected after the request but before you make your second request to other servlet. Try to hold a reference in the servlet for the servlet's life time and then try your test again. If they are still different THEN it's a classloader problem.