Matt, * I misread point 8.1. Actually, it was correct (I thought you said iterate through all the test cases). Can you put it back on your diagram ;-). Sorry.
* Point 7 is called by JspTestRedirector and not by jspRedirector.jsp * Point 8 is a doGet() that's correct but the intent is to "execute the test" * Point 9 and 10 are done by JspTestRedirector, not jspRedirector.jsp * Point 11 is correct (you can say 1..N, it was correct !). * Point 12 is executed by JspTestRedirector * Between 13 and 14 you need to add an arrow from jspRedirector.jsp to JspTestRedirector that says "get test results" (this is the equivalent of point 8) Everything else is fine. Most of the remarks above are minor, so I think you are really now understanding how it works ! ;-) * I think such a diagram really makes sense to understand Cactus. Maybe we can only show the classes that in direct interaction with the XXXTestCase (i.e. the classes that the Cactus user sees). In that case, we should drop the JspTestRedirector which is an internal classes (also there are lots of other internal classes that we are not showing so it's not fair to show this one only ... :-)). If we remove the JspTestRedirector, I think the diagram is perfect for a newcomer to understand how it works. Then we simply need to instanciate it for the 3 redirectors (ServletRedirector, jspRedirector.jsp and FilterRedirector). What do you think ? Thanks Matt for your help ! -Vincent > -----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? > > 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]>
