Hi Vincent,
We have extended the struts' ActionServlet in overriding the
processActionForward & processValidate methods.
In the processValidate, we bind an ActionForward object to request
scope after request dispatcher forward. In the
processActionForward, we bind the ActionForward object passed in as
argument to request scope and also bind the request's path info to
request scope before we invoke struts' processActionForward
implementation. Doing this enable us to just invoke our extension of
ActionServlet's process method in a testXXX method and retrieve the
correct ActionMapping, ActionForm & ActionForward objects afterwards.
The ActionErrors object is always available as struts binds it to
request scope.
In case of mutiple actions are invoked in a single request, because we
are not intercepting the chaining, the 2nd pass of an action
dispatching to another action or exiting the chain to end at a jsp or
html page would cause Cactus' RequestDispatcherWrapper.forward method
to throw a ClassCastException because the request object passed in,
after the 1st pass, is no longer Cactus' HttpServletRequestWrapper but
the webserver's own implementation of HttpServletRequest.
For the time being, we changed Cactus' code to test whether the
theRequest object passed in to the RequestDispatcherWrapper.forward
method is of type HttpServletRequestWrapper before having the
originalDispatcher do a forward.
In order to deal with this, either change the RequestDispatcher
implementation to do checking or provide protected/public getter
methods for those original objects so that we can get around the
problem by extending Cactus to do our more black box way of testing.
I thank you for looking into this.
Another question, I understand that Michael Rimov is working on
implementing threads to do concurrent testing and what is the status
of that?
Another question, this one I have no ideas on how to do, you mentioned
in a previous email that you may try to remove the ServletRedirector
and let the servlet be directly accepting http calls. Could you share
some thoughts on that?
Thanks.
Peter
"Vincent Massol" <[EMAIL PROTECTED]> on 12/14/2001 05:05:06 PM
Please respond to "Cactus Developers List"
<[EMAIL PROTECTED]>
To: "'Cactus Developers List'" <[EMAIL PROTECTED]>
cc:
Subject: RE: Preparing Cactus 1.3 release
Hi Peter,
Sorry but I don't think I understand. What is it that you can't do
with
the wrapper classes and that you could with the original classes ? Can
you give an example ?
Thanks
-Vincent
> -----Original Message-----
> From: Peter Wong [mailto:[EMAIL PROTECTED]]
> Sent: 14 December 2001 21:07
> To: Cactus Developers List
> Subject: Re: Preparing Cactus 1.3 release
>
>
>
> Hi,
>
> I wonder if it will be possible, in the 1.3 release, to provide
public
> get methods for the original objects in the ServletContextWrapper,
> ServletConfigWrapper classes, those implicit objects available in a
> TestCase classs. It appears to me that doing so would not in any way
> affect the cactus internal code and this would make my life a lot
> easier in terms of testing struts muti-actions processing in one
http
> request as our view of unit testing struts actions is more black box
> than what is proposed at the cactus site.
>
> Thank you for your consideration.
>
> Peter
>
>
>
>
> "Vincent Massol" <[EMAIL PROTECTED]> on 12/13/2001 04:15:04 PM
>
> Please respond to "Cactus Developers List"
> <[EMAIL PROTECTED]>
>
> To: <[EMAIL PROTECTED]>
> cc:
> Subject: Preparing Cactus 1.3 release
>
> Hi,
>
> I have reorganised the todo list in an effort to speed the release
of
> Cactus 1.3 and prepare for Cactus 1.4. Can you please all check that
> everything is fine with you in term of content of Cactus 1.3 ?
>
> I'm planning to release Cactus 1.3 within 1/2 weeks.
>
> Thanks.
> -Vincent
>
>
>
> --
> To unsubscribe, e-mail: <
> mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <
> mailto:[EMAIL PROTECTED]>
>
>
>
>
>
>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:cactus-dev-
> [EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:cactus-dev-
> [EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
