vmassol 01/09/25 07:27:21
Modified: docs/framework/xdocs how_it_works.xml
docs/framework/xdocs/images archi_jsp.jpg
docs/framework/xdocs/misc archi_jsp.ppt
Added: docs/framework/xdocs/images archi_filter.jpg
docs/framework/xdocs/misc archi_filter.ppt
Log:
updated architecture information with new Filter redirector and JSP redirector now
works exactly in the same way as the Servlet one.
Revision Changes Path
1.3 +53 -41 jakarta-cactus/docs/framework/xdocs/how_it_works.xml
Index: how_it_works.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/docs/framework/xdocs/how_it_works.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- how_it_works.xml 2001/09/22 19:19:54 1.2
+++ how_it_works.xml 2001/09/25 14:27:20 1.3
@@ -18,7 +18,7 @@
<note>
Cactus provides several <code>TestCase</code> classes that extends the
- JUnit <code>Testcase</code> and it also provides several kind of
+ JUnit <code>Testcase</code> and it also provides several kind of
redirectors (Servlet Redirector, JSP Redirector, ...). The diagram
above is a generic diagram which serves to explain the principles.
You'll find details for a specific redirector proxy in the next
@@ -31,10 +31,10 @@
</p>
<ol>
<li>
- The JUnit Test Runner calls a <code>YYYTestCase.runTest()</code>
- method. This method looks for a
+ The JUnit Test Runner calls a <code>YYYTestCase.runTest()</code>
+ method. This method looks for a
<code>beginXXX(ServletTestRequest)</code> method and executes it if
- one is found. This is executed on the client side (i.e. not in a
+ one is found. This is executed on the client side (i.e. not in a
server engine). The <code>ServletTestRequest</code>
parameter passed to the <code>beginXXX()</code> method is used
to set the HTTP headers, the HTTP parameters, ... that will be
@@ -47,10 +47,10 @@
(HTTP headers, HTTP parameters, ...)
</li>
<li>
- The Redirector proxy acts as a proxy on the server side for your
- test case class. It means that your test case class is instantiated
- twice : once on the client side (by the JUnit Test Runner) and once
- on the server side (by the Redirector proxy). The client side
+ The Redirector proxy acts as a proxy on the server side for your
+ test case class. It means that your test case class is instantiated
+ twice : once on the client side (by the JUnit Test Runner) and once
+ on the server side (by the Redirector proxy). The client side
instance is used for executing the
<code>beginXXX()</code> and <code>endXXX()</code> methods (see
steps 1 and 8) and the server side instance is used for executing
@@ -70,14 +70,14 @@
to override some methods in order to return simulated values.
For example, the Cactus framework can simulate an URI (i.e.
act as if this URI was called instead of the Redirector proxy
- URI). Thus, the <code>getServerName()</code>,
+ URI). Thus, the <code>getServerName()</code>,
<code>getServerPort()</code>,
<code>getRequestURI()</code>, ... methods return values based
on the simulated URI (if there is any defined by the user).
</li>
<li>
creates an HTTP Session if the user has expressed the wish
- (using the
+ (using the
<code>ServletTestRequest.setAutomaticSession(boolean)</code>
code in the <code>beginXXX()</code> method. By default a session
is always created) and the redirector fills by reflection the
@@ -86,16 +86,16 @@
</ul>
</li>
<li>
- The <code>setUp()</code>, <code>testXXX()</code>
- and <code>tearDown()</code> methods of your test class are executed
- (in that order). They are called by the Redirector proxy using
- reflection. Of course, <code>setUp()</code> and
+ The <code>setUp()</code>, <code>testXXX()</code>
+ and <code>tearDown()</code> methods of your test class are executed
+ (in that order). They are called by the Redirector proxy using
+ reflection. Of course, <code>setUp()</code> and
<code>tearDown()</code> are optional (same as in JUnit).
</li>
<li>
Your <code>testXXX()</code> method calls your server
side code to test, executing the test and using the JUnit assert API
- to assert the result (<code>assert()</code>,
+ to assert the result (<code>assert()</code>,
<code>assertEquals()</code>, <code>fail()</code>, ...)
</li>
<li>
@@ -121,35 +121,32 @@
<s2 title="Redirector Proxies">
<p>
- Cactus provides 2 implementation for the Redirector Proxy :
+ Cactus provides 3 implementations of Redirector Proxies
+ (see the <link href="howto_testcase.html">TestCase Howto</link>
+ tutorial for more details on how to use these redirectors) :
</p>
<ul>
<li>
<em>A Servlet Redirector</em>. This redirector is a servlet that
should be used for unit testing servlet methods or any java class
- that uses servlet objects. It provides the
- following implicit objects : <code>request</code>,
- <code>response</code>, <code>session</code> and <code>config</code>.
+ that uses servlet objects (<code>HttpServletRequest</code>, ...)
</li>
<li>
<em>A JSP Redirector</em>. This redirector is a JSP page that
should be used for unit testing server code that need access to
- the following objects : <code>pageContext</code> and
- <code>out</code>. These objects are provided in addition to all the
- objects provided by the Servlet Redirector. The JSP Redirector
- should be used to unit test custom Tag libraries.
+ JSP implicit objects (<code>PageContext</code>, ...). The JSP
+ Redirector should be used to unit test custom Tag libraries.
</li>
- </ul>
-
- <note>
- Testing custom JSP Tag libraries is not finalized yet and only
- tag libraries that do not use the <code>bodyContent</code> can
- currently be tested.
- </note>
+ <li>
+ <em>A Filter Redirector</em>. This redirector is a Servlet Filter
+ that should be uses for unit testing Servlet Filters or any java
+ class that uses filter objects (<code>FilterConfig</code>, ...).
+ </li>
+ </ul>
<s3 title="Servlet Redirector Proxy">
-
- <figure src="images/archi_servlet.jpg"
+
+ <figure src="images/archi_servlet.jpg"
alt="Servlet Redirector Architecture"/>
<p>
@@ -157,8 +154,8 @@
Once to execute the tests and retrieve the servlet output stream and
a second time to get the test result. This is to be able to get
the exception data (message, stack trace, ...) if the test failed.
- The test results are stored in a variable which is put in the
- <code>ServletContext</code> and then retrieved on the second HTTP
+ The test results are stored in a variable which is put in the
+ <code>ServletContext</code> and then retrieved on the second HTTP
connection.
</p>
@@ -169,13 +166,28 @@
<figure src="images/archi_jsp.jpg" alt="JSP Redirector Architecture"/>
<p>
- The client side opens 2 HTTP connections. Once to the Redirector
- JSP to execute the tests and retrieve the JSP output stream and
- a second time to the Servlet Redirector to get the test result.
- This is to be able to get the exception data (message,
- stack trace, ...) if the test failed.
- The test results are stored in a variable which is put in the
- <code>ServletContext</code> and then retrieved on the second HTTP
+ The client side opens 2 HTTP connections to the JSP redirector.
+ Once to execute the tests and retrieve the servlet output stream and
+ a second time to get the test result. This is to be able to get
+ the exception data (message, stack trace, ...) if the test failed.
+ The test results are stored in a variable which is put in the
+ <code>ServletContext</code> and then retrieved on the second HTTP
+ connection.
+ </p>
+
+ </s3>
+
+ <s3 title="Filter Redirector Proxy">
+
+ <figure src="images/archi_filter.jpg" alt="Filter Redirector
Architecture"/>
+
+ <p>
+ The client side opens 2 HTTP connections to the Filter redirector.
+ Once to execute the tests and retrieve the servlet output stream and
+ a second time to get the test result. This is to be able to get
+ the exception data (message, stack trace, ...) if the test failed.
+ The test results are stored in a variable which is put in the
+ <code>ServletContext</code> and then retrieved on the second HTTP
connection.
</p>
1.3 +76 -84 jakarta-cactus/docs/framework/xdocs/images/archi_jsp.jpg
<<Binary file>>
1.1 jakarta-cactus/docs/framework/xdocs/images/archi_filter.jpg
<<Binary file>>
1.3 +63 -78 jakarta-cactus/docs/framework/xdocs/misc/archi_jsp.ppt
<<Binary file>>
1.1 jakarta-cactus/docs/framework/xdocs/misc/archi_filter.ppt
<<Binary file>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
