>
> 2) I have seen this line of argumentation a couple of times and I have not
> been convinced that there is any validity in the interpretation of the
> following statement:
>
> > I would not do so - A servlet is meant for processing a request and send
> > a response. That's the only specified behavior that the container
> > expects from a servlet.
>
> "Processing a request" is such a generic term that allows just about
> everything to happen. Assuming I contact my home web server and run a
> servlet that has to turn on the water-heater through JNI (sorry no JINI
> compliant water-heater, yet!), query an inventory database on whether
> ingredients exist for my favourite recipe that I pass as a parameter and
> SMS to my wife through an SMS modem (sorry, WAP has no push yet:-) that I
> am coming home early and I am cooking. Would you do all that in a single
> thread?
>
> The idea that servlets are HTML-producing chunks of code was a bit of an
> underestimate in the start and nowadays with all these alternative ways to
> produce dynamic HTML it should be quite obsolete. The fact that we still
> ride on top of HTTP, and primarily use servlets as glorified CGIs to query
> databases is another long discussion.
I think the issue has been confused. "Processing Request" is what the
"service" does - It does not matter whether you're "generating" HTML or
running a water-heater. Let's not jump to quick conclusions.
> Additionally, "manipulating" the context space if done according to specs
> and the methods that are allowed in the implementation, and of course,
> under valid OOP techniques (e.g. 'grounding' on local copies) would not be
> a problem. Putting these resources back when the spec allows you to do so
> with setters is also acceptable.
1. Request and response objects should be used only in the context of a
request. Refer to the spec.
2. In a distributed container, the container may serialize/deserialize
contexts and sessions whenever required - except during the context of a
request. This is the sort of behavior that we can expect from a
distributable container with a distributable application.
Under these circumstances, object references that another thread may be
holding may not be valid outside the context of a request. In these
cases, without kludgy programming, it would be difficult to "put back"
the manipulated resources.
> Therefore, feel free to use all the Java techniques that you are aware of,
> should they fit your purpose and do not bend the specs. This last thing,
> after all, is the container's responsibility and I am sure Sun would like
> to hear of people pushing to the limits.
Disign By Contract!
Cheers
___________________________________________________________________________
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
