On Sat, 4 Aug 2001, Levent G�ndogdu wrote:
> Hi everyone,
>
> I would be so happy if someone could help me with the following problem:
>
> I have written a Servlet which is able to do background calculations which
> take some time. I don't want the user to wait for the request to complete,
> so I decided to start a thread and output a message to the user so that he
> may continue to work with the
> application until the calculations have been made. So far so good.
>
> The output of the calculation is somewhat complex. In the first approach the
> thread created a StringBuffer, put everything into that buffer and, after
> completion, that StringBuffer was sent to the user. That worked fine, but:
>
> I want the thread to be able to include JSPs in order to format the output.
> For including some URI, I need a ServletRequest and ServletResponse object
> which are passed to RequestDispatcher.include(). I decided to implement own
> versions of ServletRequest and ServletResponse, so that I could overwrite
> getWriter() and getOutputStream() in order to put the output into my own
> buffer. But, when calling RequestDispatcher.include(), I get:
>
> IllegalArgumentException: Response is not a
> javax.servlet.ServletResponseWrapper.
>
> thrown in ApplicationResponse.calculateParent().
>
> Why has the ServletReponse to be a ServletResponseWrapper?
>
Because it's required by the spec.
The deeper issue is that your extra thread is "pretending" (from the
point of view of the JSP pages you're trying to use) to be a servlet
container, but it is only doing part of the job.
> I tried wrapping my ServletResponse with a ServletResponseWrapper but still
> the same exception occurs.
>
> I thought that defining interfaces (like ServletResponse) is good for
> abstracting things and allowing developers to replace functionality. But in
> this case abstraction gets meaningless.
>
The abstraction would be fine ... if your calling class did it's part of
the bargain. But that means you have to act (from the perspective of the
JSP page you're calling) like you are Tomcat.
An additional problem you will run into, even if you solve this one, is
that the request object cannot be shared across threads either.
> Do you have any idea how to solve that?
>
A completely different strategy would be to have your extra thread do its
computations and store the data to create the results into a session
attribute. Then, when your user asked for the page to display the
results, the calculations would have already been completed (or, if the
attribute isn't there, you can display a "still working on it ..." page),
the response can be displayed in the usual way.
> Thanks in advance, everyone!
>
> Bye,
> Levo.
>
> BTW: I'm using tomcat 4.0 b5.
>
>
Craig McClanahan
