Hi,
I've started a wiki topic on the API design rules we wish to follow for
Cactus 1.6:
nagoya.apache.org/wiki/apachewiki.cgi?CactusProjectPages/ApiDesignRules
Comments welcome (you can put them directly in the wiki)
There's quite some work to achieve these design rules... :-)
Thanks
-Vincent
Hi Vincent,
I'm +0 on this. The minor drawback is the even longer package names and
that we once again will fragment big parts of the CVS history. Another
option would be to state that only documented API is public API, and
then exclude every non-public API class from the javadoc generation.
-
vmassol 2003/11/02 11:10:50
Modified:framework/src/java/share/org/apache/cactus/server
AbstractWebTestCaller.java
Log:
Check for null test results. Warn about potential error due to a load-balancer.
Revision ChangesPath
1.24 +15 -1
jakart
vmassol 2003/11/02 11:04:43
Modified:documentation/docs/xdocs faq.xml
Log:
Added answer to "Does Cactus work with load-balancers?"
Revision ChangesPath
1.19 +15 -0 jakarta-cactus/documentation/docs/xdocs/faq.xml
Index: faq.xml
=
> -Original Message-
> From: Christopher Lenz [mailto:[EMAIL PROTECTED]
> Sent: 02 November 2003 19:36
> To: Cactus Developers List
> Subject: Re: Use HTTP header instead of unique ID?
>
> Vincent Massol wrote:
> > To summarize, we have 2 possible solutions:
> >
> > Solution 1:
> > - 2 r
Vincent Massol wrote:
To summarize, we have 2 possible solutions:
Solution 1:
- 2 requests
- test result stored in application scope under a unique key
- limitation: does not work with load balancer, even with
session-affinity load balancer
Solution 2:
- 2 requests
- test result stored in session
> -Original Message-
> From: Nicholas Lesiecki [mailto:[EMAIL PROTECTED]
> Sent: 02 November 2003 17:40
> To: Cactus Developers List
> Subject: Re: Use HTTP header instead of unique ID?
>
> OK, so we have several tensions we need to resolve. Our basic
requirements
> are:
>
> 1) The exec
> -Original Message-
> From: Nicholas Lesiecki [mailto:[EMAIL PROTECTED]
> Sent: 02 November 2003 17:14
> To: Cactus Developers List
> Subject: Re: Serializing test case classes
>
> (Sorry I'm late in jumping onto this thread)
>
> This seems like a good idea because it will finally elim
OK, so we have several tensions we need to resolve. Our basic requirements
are:
1) The execution of a servlet-based test case must be allowed to pass a text
response back to the client for inspection and verification.
2) The test case must be able to retrieve its results from the server,
includin
(Sorry I'm late in jumping onto this thread)
This seems like a good idea because it will finally eliminate the
counterintuitive behavior of the test state not persisting from the client
to the server. However, will the test be reserialized and sent back to the
client to be finished? It seems like
10 matches
Mail list logo