>>> "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?
>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 suppose any higher-end container is going to allow you
>to lock down a servlet, but isn't that fighting against
>the servlet architecture?
No... I don't think so.
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...
IMHO if you can get an implementation that does what you want you're
there. This is really an implementation issue.
>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...
Yeah... but that's what I'm saying. The spec is there partly to make
us all aware of the 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.
Even in the the servlet spec there are areas of ambiguity!
Nic
___________________________________________________________________________
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
