> -----Original Message-----
> From: Peter Wong [mailto:[EMAIL PROTECTED]]
> Sent: 18 December 2001 19:46
> To: Cactus Developers List
> Cc: Dan Sterling
> Subject: RE: Preparing Cactus 1.3 release
>
>
>
> 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.
>
I'm not sure I understand everything. First, what are you trying to
achieve ? Unit testing of Struts Action objects ? If so, have you looked
at http://strutstestcase.sourceforge.net/ ?
Then, are you saying that 2 forwards in a row will fail ?
> 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?
>
I have had no news. That was an idea he had but I don't know if he has
progressed on the subject.
> 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?
>
Yes, my idea was to try (for some future version of Cactus) to provide a
"transparent" interceptor for each servlet/jsp/filter/ejb/... to unit
test instead of providing visible ones that you need to configure
(ServletRedirector, JspRedirector, ...). This is still an idea but I'd
like to experiment with it. There are several ways of doing this :
- at the source code level, by using some tool like AspectJ (BTW this is
the current Cactus approach to automatic logging),
- at the bytecode level, by using some tool like Jakarta BCEL,
- at the debugger level, by using JPDA (see
http://www.javaworld.com/javaworld/jw-12-2001/jw-1214-jylog.html?)
-Vincent
> 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: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]>
