"K.V. Chandrinos" wrote:
> [skipping the rhetoric, focusing on the details]
> I take the arguments one-by-one:
>
> "You should not get access to this information because it:
>
> * Is dangerous -- what stops you from calling init() and destroy()
> yourself, and thereby messing up the state your servlet thinks it
> is in versus what the servlet engine thinks it is in?"
>
>
> Ans.: Hopefully, the servlet engine:-) I do not see why the system could
> not stop me from calling these two particular methods that could 'mess up'
> the state,
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?
> although in principle, I also do not see why not a privileged
> MasterServlet could not be authorised with loading and unloading other
> servlets programmatically. Millions of people would kill for that.
>
That's sort of what JSP does, although it does not really unload the old
servlet class when you recompile -- it creates a new one with a different
name. There are significant restrictions (based on the way Java class loaders
work) that limit the flexibility of a "master servlet" here.
>
> "* Can potentially breach privacy -- application designers frequently
> store privileged information in servlet class variables (such as
> JDBC connections that are preinitialized) that could be potentially
> abused if they were accessible from any anonymous servlet that
> happens to be accessed. This argument also explains why you can
> not get a reference to any user session other than your own either."
>
> Ans.: This is a privacy issue that Java has to deal with in general.
> Blocking access to data is an effective but not concrete solution to
> privacy, otherwise 'public' and 'private' woudn't be in use.
>
Well, there's always PHP and PERL if you don't like the restrictions of the
Java programming language :-).
>
> "* Leads to incredibly bad designs -- you will be tempted to use
> methods and variables in your servlet class to store shared state
> information in a servlet, instead of using an appropriate object
> oriented design for the shared information."
>
> Ans.: Saving me from myself then? As if current state of affairs does not
> allow me to go for bad designs:-? If one is OO-elastic enough to allow a
> system's state be hidden, I cannot see how far worse my designs to
> circumvent this can go... Probably, I will have to rewrite some code in a
> wonderful 'reuse' illustration.
>
Protection is not just from yourself.
Any significant sized application is going to be developed by multiple people,
and minimizing side effects when you make changes is an important goal in
developing your design. When variables are accessible only within a class
(private scope), I can examine the code and see 100% of the occurrences of
variable references, within the class I am looking at. If the variable is
accessible from outside, this is no longer the case.
The history of computing is rife with examples where sharing global variables
indiscriminantly is a bad idea -- at least as far back as Fortran
COMMON blocks where you had no clue what module is scribbling on your data.
There is also a relevant cliche in English that is appropriate to this
situation: "if the only tool you have is a hammer, every problem looks like a
nail." Trying to use ANY architectural pattern (servlets in this case) to
solve all your problems (shared data access) is a case in point.
>
> "* Not portable to distributed environments -- references to Java
> objects only work within the same JVM. What do you do if the "other"
> servlet you are trying to talk to is actually on a different server?"
>
> Ans.: I plead with the system to provide me a reference it ALREADY HAS in
> order to delegate requests to that other JVM.
>
Which doesn't address the issue that you cannot do a getServlet() call and get
a reference to a servlet instance in a different JVM. If you care about
scalability of your app, you will care about this issue. If not, then it's no
big deal.
[not interested in arguing philosophy, I skipped the rest ... I was only
responding to several people's desire for a specific list of "what's wrong
with getServlet()]
Craig
___________________________________________________________________________
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
