Bob Davison wrote:
>
> On 11/06/2001 15:23:18 jariw wrote:
<snip>
>
> Jari,
>
> The "request results before available" bug is in the Apache bug database,
> #1612. A patch is with Vincent but I don't think that it has been applied yet.
>
Excellent. I have actually tried going down the first route I suggested,
for the reason that I'd quite like to be able to test what has happened
before the forward or include is called. That way I can split tests into
checking that an "action" has achieved the right results, separate to
checking that a JSP page outputs the results correctly. A sort of divide
and conquer withing the "Model 2" world :)
I've ended up with a "dispatch immediate" boolean to allow me to delay
the dispatch of the forward or include request within the test. Although
I'm not sure whether that's really in the spirit of how to perform this
sort of testing, given that delaying dispatch changes the way the
request would normally be handled. Not sure how nice this is codewise
either :) - it means the return of control to the ServletHttpClient
class comes under the control of the test. I have also stored the "path"
that the RequestDispatcher is created for in the
RequestDispatcherWrapper- this allows me to check that the servlet is
forwarding to the correct page.
I can see why the lock is absolutely needed, however I can also see
value in knowing what path a servlet is forwarding to or including, and
in being able to delay.
What are your opinions on adding the path or the ability to delay to the
RequestDispatcherWrapper and HttpServletRequest classes?
Jari
>
> .../Bob
>
> p.s. I am using Cactus to test servlets that forward to JSP's and am having no
> problems, apart from bug #1612 that is!
>
Do you perform a test that covers the whole servlet and JSP call? or do
you try to split out the test of the servlet and the JSP parts?
If the latter, how have you managed testing the JSP portion of the call?
(I have yet to try the Jsp testing ability of cactus... so this may be
easy, don't know at the moment.)
Do you know if anyone has done any work in defining a "contract" between
servlet and JSP? i.e. something to define the interface between servlet
and JSP, so that you know what RQPairs are expected by a servlet, or
what form parameters are expected, and similarly what objects a JSP page
expects in the request?
something like:
public interface RequestContract
{
public RQInfo[] getRQPairs();
public RQAttribute[] getOutputAttributes();
}
public interface RQInfo
{
public String getName();
public Class getType(); //
public boolean isOptional();
}
public interface RQAttribute
{
public String getKey();
public Object getValue();
// etc;
}
Parallel working of server side and interface developers on Java and JSP
code can cause us problems at integration time.
I wonder whether formally expressing the interface between Servlet and
JSP would help us by providing a "typed" interface to check against much
earlier in the project. Trouble with JSP's is that it is all done by
names and the service(request, response) method. This means we currently
lose all type safety between the servlet and the "call" to the JSP.
Seems to me that requestdispatcher.forward(request, response) call is
just a badly typed method call, and that introducing some structure for
servlet developers, and for JSP developers to work from would be a "Good
Thing".
You could even perform validation in a custom tag library that the JSP
forward call has been correctly made (everything expected is in scope).
What do people think of that idea?
And excuse the long mail, but this is an area that has "bitten" me on
several projects.
Jari
--
Jari Worsley
Senior Programmer
Hyperlink Interactive Ltd
