"K.V. Chandrinos" wrote:
> [snipped quote from Jason's book]
>
> I think that in view of the above you would agree that casting a servlet
> IS NOT like casting any other class,
This is an incorrect conclusion.
The reason Jason points out that there might be a problem related to class casting a
servlet instance is because of the way auto-reloading is implemented in many older
servlet engines. This same problem applies to *any* Java class that is reloaded by the
"new" class loader, and you are trying to use a reference to an old instance (or vice
versa). It is not just servlet classes. The example you quoted is simply one
illustration of the general problem.
Servlet containers that implement the 2.2 (or later) version of the spec are explicitly
required to ensure that such class casting problems do not occur, even if they
implement class reloading.
> and the legitimate reasons I
> mentioned are indeed legitimate whether the methods are sanctioned by Sun
> or not. Jason suggests three workarounds for the above problem, last of
> which is the interface solution I mentioned. I am afraid that the
> .setAttribute() approach would run the same casting 'danger' like above.
> I do not see why your 'this' which is referred to by the attribute won't
> be different if the servlet is reloaded and the init() runs again.
>
You are correct here -- the class cast problems can occur in any class, not just
servlets. However, modern servlet containers do a much better job at avoiding this,
and engines >= version 2.2 are required to avoid it.
>
> Deprecating getServlet() means you are left to do your own
> context-managing. That's quite honest on the part of Sun, albeit a bit
> delayed. However, as I am not versed in the intrinsics of distributed
> context creation I am left with the naive question: Since some 'entity' in
> my servlet-system will know which servlet is loaded where, otherwise the
> system wouldn't work, why shouldn't I get access to this information, even
> under prvillege, through a method?
>
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?
* 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.
* 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.
* 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?
Bottom line -- if you find the lack of getServlet() to be restrictive, this is a pretty
good sign you should go back and review your design for adherence to good
object-oriented architecture principles. It means you are trying to use servlets for
what they are not.
>
> Kostas
>
Craig McClanahan\
___________________________________________________________________________
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
