Date: 2004-02-22T11:34:04 Editor: VincentMassol <[EMAIL PROTECTED]> Wiki: Jakarta Cactus Wiki Page: Cactus2Proposal URL: http://wiki.apache.org/jakarta-cactus/Cactus2Proposal
Added "CactusTestSetup vs Static variables" design question Change Log: ------------------------------------------------------------------------------ @@ -29,3 +29,13 @@ My preference goes to the Socket listener solution. I wish we could find a way to make it work for concurrent tests. -- VincentMassol Why won't socket listener work for multi-threaded tests? --NickLesiecki + +== CactusTestSetup vs Static variables == + +In order to load configuration parameters + setup the socket listener we need to have some initialization code. There are 2 possibilities: + * By using a JUnit TestSetup (CactusTestSetup class) in which the initialization is done in setUp() (and the shutdown is done in tearDown()) + * By using Aspects to intercept either all testXXX() method calls or TestCase constructors. In these interception, use a static variable to check if Cactus has already been initialized or not. + +Both have pros and cons. However, the biggest drawback for the first solution (CactusTestSetup) is that it does not offer a solution on the server side (there is no JUnit Test Runner on the server side). Thus for the server side, there is only a single generic solution I can imagine: using a generic Aspects to intercept Cactus user-defined Aspects and using a static variable to remember if the Cactus system has already been initialized. Note that using Java system properties would be enough for passing configuration data but not enough for a proper initialization phase (which is needed for example if we're using a component-based approach like PicoContainer). The other problem with the TestSetup solution is that it is more complex for Cactus users who need to wrap all tests in a test suite. + +Thus, I think the Aspect initialization is probably the best route. Any other idea? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
