Craig R. McClanahan wrote:
>In a 2.0-compatible servlet, I can execute the following code:
>
> Servlet myServlet = getServletContext().getServlet("myservletname");
> myServlet.destroy();
>
>and there is not a thing the servlet engine can do about it. How do you
>propose this protection be implemented?
>
This kind of protection is easily implemented. You forget that
Servlet, ServletConfig, ServletContext, ServletRequest and
ServletResponse are all interfaces. So you may write your own servlet
classes implementing these as you wish. For example you may implement
getServlet() like this;
public getServlet(String name) throws ServletException {
throw new ServletException("Access denied.");
}
I belive this point have been missing throughout the discussion. Also
when casting to a class, it's possible, as you all know, to cast to an
interface, which will not create an exception even if the object
changes in other regards.
Anyway, I'll join the people advocating not calling a method in
another servlet. The reason is that it's impossible to know the state
of the servlet as related to the servlet runner, and almost just as
important, and which many has already pointed out, it doesn't scale.
In order to implement scalable inter-servlet, inter-jvm,
-communication, I suggest making a CORBA/RMI server implementing
Servlet and ServletConfig.
Trond Sausjord
--
A common mistake that people make when trying to design
something completely foolproof is to underestimate the
ingenuity of complete fools. -- Douglas Adams
___________________________________________________________________________
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
