First off, I want to stress that if we're talking about a
quickie one-off servlet, then none of this is likely to
matter. With that in mind...
Nic Ferrier wrote:
>
> > "Christopher K. St. John" <[EMAIL PROTECTED]> 01-Nov-00 9:44:35 PM
> >
> > But the context can be taken up and down as well :-)
>
> True... but if that happens don't you want any listening socket to go
> away?
>
The problem is that the servlet container is not going to
know about your socket, so it (or the admin) might decide to
shut down your servlet in the middle of a socket communication.
You don't have any control over that.
Part of the problem is the tension between servlets-as
gateway-to-ejb-container-or-equivalent and servlets-as
self-contained-web-applications.
In this case, there aren't enough details to decide
which is the more appropriate model.
> >My assumption was that a higher-end container would
> >want to be able to clear the decks completely if it
> >needed to, and then reload as needed.
>
> I think it's mainly intended for admin reasons (an admin can reload a
> context and take one out of service and so on).
>
I was assuming that in addition to admin considerations,
a long running servlet container might want to deactivate
unused webapps if it started to run out of resources. I'd
be interested in hearing the lowdown...
> I've never seen why containers reload servlets... I know Jserv used
> to do it (I don't think Tomcat does BTW). It doesn't seem sensible to
> me... certainly Paperclips has never and will never do it...
>
In addition to the possibility above, I can imagine that
ISPs hosting servlets for customers would also probably
find it useful to be able to shutdown/restart a particular
webapp without taking down all the other webapps. Same goes
for high availability systems that want to upgrade code on
the fly.
Again, there's a tension between the different possible
deployment scenarios. What's total overkill in one situation
could be an absolute requirement in another.
> IMHO if you can get an implementation that does what you want you're
> there. This is really an implementation issue.
>
But maybe be next release of the container will have
an expanded feature set. Or maybe your VP of technology
has a friend at Allaire and decides to go with JRun, etc.
As long as the spec explicitly says it's possible, it
seems like a good idea to allow for it.
> >Still, there are going to be some nasty suprises for
> >people who decide to upgrade to a high-end container and
> >aren't aware of the potential issues...
>
> If you're serious about being a good
> administrator for a servlet based platform you should have a good
> understanding of the spec and of how your chosen engine implements
> it.
>
But depending on how it's deployed, the person writing the
app and the person administering the container may have no
contact with one another.
-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
