Nic Ferrier wrote:
>
> >>> "Christopher K. St. John" <[EMAIL PROTECTED]> 01-Nov-00 2:59:36 PM
> >>>
>
> >A safer/simpler architecture might be to have a non-servlet
> >service that could be started/shutdown based on requests
> >handled by the servlet.
>
> Another way round it would be to put a reference to the ServerSocket
> in the servlet container's context attributes.
>
But the context can be taken up and down as well :-)
At least, that was how I read the spec. I'm a little
unclear on some of the lifecycle issues involving the
webapp as a whole (I'm thinking ServletContextListener)
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.
> But I think the best way would be to check whether your servlet
> container does reloads in the way Chris describes. If it does...
> get another one /8->
>
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?
I agree that there's a engineering tradeoff, if you just
want to write a quick one-off then you don't want to be
forced to consider all the lifecycle issues. It would be
easy to turn the relatively-simple servlet 2.0 spec into
something that looked like the EJB spec.
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...
-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
