Hi Vincent,
Yes, we are trying to test struts actions. I have been following the
discussion on using cactus to test struts actions in the mailing list.
I have looked at Erik Hatcher's work and also Deryl Seale's work at
sourceforge. As I stated, we are testing our business action
processing in a more black box way. We do not break up struts'
ActionServlet.process() method in our test and then call
Action.perform() method directly. Hence, we are not using either
Erik's or Deryl's work.
Yes, using our way of testing struts action(ie, once an ActionServlet
instance is retrieved from webserver, and then invoking
ActionServlet.process(.) method), ClassCastException will be thrown if
the request results in multiple actions being forwarded to starting at
the 2nd forward. This happens because the first action gets Cactus'
HttpServletRequestWrapper instance(and it works fine) but the 2nd and
later actions get ther webserver's implementation of
HttpServletRequest which causes the ClassCastException.
If you would like to look at my code, I will be more than happy to
send it and we welcome your comment.
Thank you for looking into this.
As for the other 2 topics, let me take a look and see if there is
anything that I can do. Thanks for pointing out the 3 different
approaches. I appreciate that. We are very interested in not having a
Cactus redirector servlet intercepting a http request before getting
to our extension of ActionServlet.
Peter
"Vincent Massol" <[EMAIL PROTECTED]> on 12/18/2001 03:30:48 PM
Please respond to "Cactus Developers List"
<[EMAIL PROTECTED]>
To: "'Cactus Developers List'" <[EMAIL PROTECTED]>
cc:
Subject: RE: Preparing Cactus 1.3 release
> -----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]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
