"Steven J. Owens" wrote:
> Hi folks,
>
> This is related to the earlier discussion of coding servlets to
> reload config data dynamically. Is there any sort of standard
> "out-of-band" communication capability in the servlet API?
>
No. What you see in the API is what you get. But all is not lost with
regards to re-reading config data ... see below.
>
> The only way I'm currently aware of to communicate with a servlet
> is to invoke it as a URL (i.e. doPost/doGet, etc), and since those
> methods are the ones that do most of the workhorse tasks, I'd rather
> not have the code be evaluated for every request. I'm thinking of
> overriding one of the less-used sub-service methods, like doPut() or
> doDelete(), to trigger the reload. This feels like a real kludge, but
> is there any alternative?
>
What's wrong with calling doGet() / doPost() on every appropriate request?
There are lots of ways to "short circuit" the normal processing that are
entirely within the current standard, and quite understandable to boot. The
simplest example I can think of uses the "extra path" feature of the servlet
API.
Let's say you have your servlet mapped to the URL
"http://www.mycompany.com/foo". A trivially simple way to trigger reloading
configuration information is by making a request to URL
"http://www.mycompany.com/foo/reload" where you have code like this at the
beginning of the doGet() method:
String pathInfo = request.getPathInfo();
if ((pathInfo != null) && pathInfo.equals("/reload")) {
... reload the configuration file ...
... construct an output page that says "reload done" ...
return;
}
... do what the servlet normally does ...
>
> I guess the "right" answer is to override service() and add my
> own flavor HTTP operation, RELOAD. Of course then I have to write a c
> special client to send a RELOAD operation.
>
Although the "extra path" feature will work just fine, you might actually
prefer to do something like this anyway so that people who figure out what's
going on do not start a "denial of service" attach by repeatedly sending
reload commands from their browser. At least you'd force them to write a
client program to do it for them, although that's not a whole lot of help.
>
> Steven J. Owens
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
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
