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
