On 11/06/2001 15:23:18 jariw wrote:
> Ok.
>
> Take 2.
>
> The fix allows the original code to run through. however this screws up
> the test itself :(
>
> Why? because the response is returned immediately, which means the
> client code immediately tries to get the result of the test, which leads
> to all sorts of concurrency fun :). In my simple example the cactus
> client code calls to get the result before the unit test has finished,
> which isn't much use really.
>
> I can see two ways around this which are (and which I will try):
>
> 1. Save the call until the test has finished - i.e. change the
> RequestDispatcherWrapper to wait until prompted before calling the
> forward - or even just "swallow" the forward and do nothing with it.
> so the order would be:
>
> client -> servlettestredirector- -> servlettestcaller -> calls a Test.
>
> in Test - do set up, call some servlet method that tries to do a
> requestdispatcher.forward(request, response). then execute rest of test
> method, this would allow you to do things like check that you have
> actually forward to the right path which could be useful.
>
> It seems ServletHttpClient class just ignores results of the first
> connection that triggers the method call on the server, so possibly just
> ignore and don't do the forward. In fact looking at ServletTestCase
> and AbstractTestCase , the stream coming back from the first request is
> totally ignored by the client code.
>
> Then the second connection that gets the results could just carry on as
> normal.
>
> or
>
> 2. Put in some sort of lock in the servletcontext to prevent the second
> connection's thread from trying to get the results until the
> ServletTestCase called by the first request has finished running.
>
>
> Any comments on which is best?
>
> am I barking up the wrong tree entirely? Is anyone else trying to do
> stuff like this?
>
> Jari
>
>
>
> --
> Jari Worsley
> Senior Programmer
> Hyperlink Interactive Ltd
Jari,
The "request results before available" bug is in the Apache bug database,
#1612. A patch is with Vincent but I don't think that it has been applied yet.
The patch implements a lock on the setting/requesting of the results as your
point 2. It also ensures that any output of the test is fully read before
attempting to get the results. This is to prevent the test result request from
deadlocking with a test that blocks on output.
.../Bob
p.s. I am using Cactus to test servlets that forward to JSP's and am having no
problems, apart from bug #1612 that is!
-----------------------------------------------------------------
Visit our Internet site at http://www.reuters.com
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Reuters Ltd.
