So, then, what if we are not explicitly setting up different servlet
contexts, so that our servlets just load into the default context? Are we
guaranteed that within the default context, we will only get one instance
of our singleton object?
For the singleton object to be workable, it would seem that you would
need a guarantee of NOT one for the whole servlet engine, but definitely
one for each logical servlet context.
Thanks!
-Bryan
At 10:20 AM 10/20/2000 -0500, you wrote:
>Charles Chen wrote:
>>
>> I believe someone (Christopher K?) has already answered this question that
>> although in practice, this should be the case;
>>
>
> Actually, in both theory and practice different classloaders
>will definitely be used to load the classes in different
>servlet contexts.
>
>
>> Why would Java do something like this? I wonder what is the reason
>> behind this spec.....
>>
>
> Gogul Singh posted a reference to a paper on this:
>
> <URL:http://www.javageeks.com/Papers/JavaStatics/index.html>
>
> The idea is that if you've got two "web applications" they should
>be independant of each other, even if they are running in the same
>JVM.
>
> Think about the case where an isp wants to run a single servlet
>container for all the customers on a particular machine. There
>are no guarantees that what one customer means by "myPackage.myClass"
>is the same as what another customer means.
>
> Even if it is the same class, then the class statics should not
>be shared across web apps (if they are, the webapps might get a
>nasty suprise)
>
> Using different classloaders provides a "class sandbox".
>
> There can be a special shared class sandbox, however, if the
>servlet container supports it. That's an area where there are
>a set of classes that all the servlet contexts can see and share.
>
> Most of the time, though, classes in one servlet context should
>be completely separate from classes in another servlet context,
>and multiple classloaders let you do that.
>
>
>
>-cks
>
>___________________________________________________________________________
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff SERVLET-INTEREST".
>
>Archives: http://archives.java.sun.com/archives/servlet-interest.html
>Resources: http://java.sun.com/products/servlet/external-resources.html
>LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
--==================================--
Bryan Roach <[EMAIL PROTECTED]>
National Center for Supercomputing Applications
Research Programmer -- Communications Group
217.265.0462
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
