See inline > -----Original Message----- > From: Matt Sullivan [mailto:[EMAIL PROTECTED]] > Sent: 13 February 2002 21:15 > To: Cactus Users List > Subject: Re: setURL question > > Vincent, > > Thank you very much for the clarifications. It did seem that 8.1 reflects > the > how_it_works.html description #5. I have updated the diagram - hopefully > with > more accuracy ;-) > > Nick, > > Your response really awoke me to the bad assumption I was using for my > test > approach. > > It seems that I need to craft a redirector that directs the request at my > running application server based on the ServletURL and other request > parameters. Am I getting closer?
Not sure I understand that ! By craft do you mean to implement one ? If so the answer is probably no :-). The goal of Cactus is to do unit tests, i.e. test directly a given method, without going through the standard path to reach the method. We're taking a shortcut (the Redirector) to directly go to your method because, in a given test case (i.e. a testXXX() method) we're only interested in testing a method (not the full path). By having several tests you are effectively ensuring you're testing the full application. Hope it is more clear. -Vincent > > Thanks again, > Matt > > <Copied from Nicholas Lesiecki email 13 Feb 2002 13:36:24 -0700> > > > Hmmm, this is the third or so time someone has misunderstood that the > > client side web request does not affect the actual URL cactus calls. > > Is there anything we can/should do to warn people in the code? Maybe > > a log entry? > > "Warning: setURL will not affect the actual http request, which is > > always determined by the Cactus.properties file." > > > > What do people think? > > > > Cheers, > > Nick > > > Vincent Massol wrote: > > > > Matt, > > > > Yes, you're getting closer :-). Everything goes through the redirector. > > The setURL is simply there in case you're manipulating the request URL > > in your code under test and you're expecting some specific value. > > > > WRT to your sequence diagram (a nice one BTW, it would be good to put it > > on the cactus web site if you're ok to donate it), here are some > > comments : > > > > 1/ If you're using JspTestCase, the corresponding Cactus redirector is > > implemented as a JSP Page (not a servlet although I agree a JSP is a > > servlet). Same, if you're using FilterTestCase, the corresponding Cactus > > redirector is implemented as a Filter (not a servlet although a Filter > > can be viewed as a servlet). > > > > 2/ Step 3 and 4 are correct. Connection goes to the Redirector. > > > > 3/ Step 6 is not completely correct. The redirector does passes to your > > test case class the implicit objects (some are wrapped, like the > > HttpServletRequest, some are not wrapped, like the HttpServletResponse). > > But it has nothing to do with the client side WebRequest object. > > > > 4/ 8.1 is not correct. The loop is not done on the server side but on > > the client side by the JUnit Test Runner. > > > > 5/ Step 10 is not "send test results" but "request test result" (no > > plural, it is done test by test) > > > > 6/ Step 11 is not correct. The WebResponse object is created on the > > client side in step 5 (that is the WebResponse you get in > > endXXX(WebResponse)) > > > > Cheers, > > -Vincent > > > > < snipped> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
