You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-user@jakarta.apache.org by Vincent Massol <vm...@octo.com> on 2002/02/13 22:25:37 UTC

How to improve understanding of Cactus (WAS RE: setURL question)

... And/Or deprecate setURL() and replace it with something like
setSimulatedURL(). Would it help ?

More generally, I think there are 2 things that are difficult to
understand (from the questions we get on the list) :

1/ the fact that there is a client side and a server side (and thus 2
classpaths)

2/ the fact that the same TestCase is instanciated both on the client
side and on the server side

On the bright side, I've noticed fewer questions WRT to the classpath
for the past few months. Maybe the "Getting Started" web page is paying
off.

Putting a UML diagram such as the one that Matt has sent would probably
help to understand how Cactus works ? We could put it in the
Architecture page and make sure this page is a must read in the "Getting
Started" guide ?

In the end the Cactus users are the best to answer our questions. Cactus
users, what do you think ?

Thanks
-Vincent

P.S.: I'm also worried that putting too good a documentation will lower
the traffic on the mailing-list ;-) .... 

> -----Original Message-----
> From: Nicholas Lesiecki [mailto:nick@eblox.com]
> Sent: 13 February 2002 20:36
> To: Cactus Users List
> Subject: RE: setURL question
> 
> 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
> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@octo.com]
> Sent: Wednesday, February 13, 2002 10:20 AM
> To: 'Cactus Users List'
> Subject: RE: setURL question
> 
> 
> 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
> 
> 
> 
> > -----Original Message-----
> > From: Matt Sullivan [mailto:matt.sullivan@bea.com]
> > Sent: 13 February 2002 16:06
> > To: Cactus Users List
> > Subject: Re: setURL question
> >
> > Vincent,
> >
> > In trying to understand where I need a clue, I cobbled together the
> > attached
> > sequence diagram.  As I understand it I was working under the
> assumption
> > that
> > the setURL in step 2.3 provided the Redirector Servlet with a URI
that
> > would be
> > used to redirect the request on the server side.
> >
> > However, it seems that I need to use a servlet that is invoked with
> the
> > wrapped
> > WebRequest to handle the redirection on the server side.
> >
> > Am I getting closer?
> >
> > Thanks,
> > Matt
> >
> > Vincent Massol wrote:
> > >
> > > Matt,
> > >
> > > I'm not sure I understand correctly. Correct me if I'm wrong in my
> > > understanding of what you're trying to achieve.
> > >
> > > The WebRequest.setURL() is used to simulate a request to the
> specified
> > > URL. It does not connect to it. The cactus client side always
makes
> a
> > > HTTP connection to the Cactus Redirector. However, the servlet
> implicit
> > > objects (request, config, context, etc) are wrapped to return the
> > > simulated URL when asked for it.
> > >
> > > Hope it helps.
> > > -Vincent
> > >
> > > Note: I've not looked yet in the file you've provided as I wanted
to
> get
> > > this clear before. I will it you tell me that this was also your
> > > understanding. Thanks.
> > >
> > > > -----Original Message-----
> > > > From: Matt Sullivan [mailto:matt.sullivan@bea.com]
> > > > Sent: 12 February 2002 20:41
> > > > To: Cactus Users List
> > > > Subject: setURL question
> > > >
> > > > First, very cool tool!
> > > >
> > > > My environment:
> > > >  WebLogic Server 6.1
> > > >  WebLogic Commerce Server 3.5
> > > >  JDK 1.3.1_01
> > > >  Cactus 1.2 (2.2)
> > > >
> > > > My application code currently works.  When my code invokes
> WebLogic
> > > > Commerce
> > > > Server Webflow I encounter no problems.  Typing the URI into a
> browser
> > > > directly
> > > > works.  My attempts to invoke the same URI with setURL() has
been
> > > > unsuccessful.
> > > >
> > > > Any guidance is very much appreciated.
> > > >
> > > > The attached file contains debugging information.
> > > >
> > > > Thanks in advance,
> > > > Matt
> > >
> > > --
> > > To unsubscribe, e-mail:   <mailto:cactus-user-
> > unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail: <mailto:cactus-user-
> > help@jakarta.apache.org>
> 
> 
> 
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:cactus-user-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:cactus-user-
> help@jakarta.apache.org>
> 




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>