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 scope under a unique key - limitation: code that expects (request.getSession(false) == null) cannot be tested!
Hmm, I wonder if it would be possible to change our RequestWrapper to behave differently depending on whether the session was created by Cactus or by the test code. Might get rather involved though.
- advantage to solution 1: works with session-affinity load balancer (but not with dumb load balancers).
Thus solution 1 seems better to me (although not perfect). This is the current solution (apart from the unique key which can be implemented relatively easily).
First, I wonder whether the load-balancer scenario is actually important to Cactus. Isn't this similar to the HTTP/SSL discussion we had recently?
[Note that I haven't really put much thought into this, neither have I really worked with load-balanced environments yet, so this may be totally off ;-) ]
Anyway, I think it would be possible to use sessions to store the test results, *if*:
- we'd provide a configuration parameter to explicitly enable implicit
session creation by Cactus
- our request wrapper would hide the session if it was created by
Cactus only for storing the test results
- we'd automatically invalidate any session created this way after the
second request, so that the server doesn't need to hold on to one
session per test (only timing them out after half an hour or so)
The code for actually storing and retrieving the test results could be rather simple by simply always looking first in session scope and falling back to application scope.
This would be some work though, and it would be much simpler to simply say "Cactus currently doesn't work in clustered environments" :-).
-chris
-- Christopher Lenz /=/ cmlenz at gmx.de
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
