At 12:02 AM 05/23/2000 -0400, Varalakshmi Allamaraju wrote:
>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 and sending a response in terms of an HttpServlet makes
sense in
what you are saying. But that is too limited a vision for using servlets. A
Generic servlet just implements
a service. True that the service is called in a separate thread, but it does
not mean that threads
cannot be used for processing by the service implementor. Here is what I
know:
1. A servlet class can implement a Runnable interface.
2. A servlet does not always have to be something that has to respond to a
service.
While implementing threads it has to be kept in mind that threads execute
until
the Virtual
machine exits if not cleaned up. This means in most cases even if the servlet
is reloaded,
threads that are not terminated from their run() will continue to run till the
VM restarts.
>
>I'm not going to disprove about your applications working or not. It all
>depends on what resources you're using during these threads. As long as
>you don't use any resources maintained by the container
>(request/response objects, session objects, context etc.), you're safe.
>This is because, all these resources are not guaranteed to be available
>outside the context of a request. Things might still work - but you can
>not guarantee in a production environment.
I agree there that container objects may not be guaranteed to exist outside of
the servlet context.
What I have to say is that as long as you are aware of what can happen and
what
cannot you
can make decisions on how best the implementation can be done.
>Keeping the original intent of servlets in mind-
I am sorry. What was the original intent again? How many creators have been
able to foretell
everything that is possible with their creation? It is the ability to use
something wildly beyond its
intented use that makes the object great. What was java created for? To quote
from Jason Hunter's
book: "Servlets allow developers to to extend and customize any Java enabled
server - a web server,
a mail server, an application server, or any custom server- with a hitherto
unkown degree of portability,
flexibility and ease."
>I would not implement such things. The rest is a matter of choice.
It is safe to assume that a group of prefessional developers like us would not
put systems on the line.
In our case we had to use threads and we did enough research to figure out the
limitations and flexibility.
>Just on the lighter side - I've heard of a story where a team struggled
>to figure out why their app server (hosting servlets) is crashing. They
>could not find any clue from the server logs. Finally, they figured out
>that some of the servlets have System.exit() statements during exception
>handling! What do we conclude from this?
"We" as in who? I don't know about others and I don't speak fo them, but my
perspective is
to learn and not to conlcude after reading 4 sentences like the ones above. I
think that you are
limiting yourself too much just based on what you see in the specs and on
examples like the above.
Technologies like these need to be explored and not worked in a box.
Regards..
Rajesh Nair
[EMAIL PROTECTED]
Ph: 913 599 7201
----------
R&D
Informix Software
___________________________________________________________________________
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
