Cactus2Proposal

Cactus v2

This page is for discussing the Cactus v2 architecture proposal.

Status (13/02/2004)

• First non-functioning "prototype" of Cactus v2 finished. This prototype relies on Maven to build and is really only a proof of concept we needed to learn how to use AspectWerkz and how to automate its usage using Maven.

• Created an AspectWerkz plugin for Maven in the process.

• Committed code in jakarta-cactus/scratchpad/cactus2/.

• ATM, the Cactus tests are not yet run in the server. We need to plug the Ant integration front.

• The next step is to have the tests run on the server side and to write the socket listener code so that the server side knows which test to execute.

• In the future I believe we'll need an Ant <cactify> task which does the weaving and calls out directly AspectWerkz without going through the AspectWerkz plugin for Maven.

• At this point in time, I have only looked at offline weaving. In the future we'll need to look at runtime weaving too I think.

Socket listener vs passing parameters to server side

There's a need to reconcile test code that is executed on the client side and test code executed on the server side. In other words a test that starts on the client side needs to be continued on the server side. There's also a need to pass back test result from server side to client side.

There are 2 options for doing this:

• Socket listener: by using a socket listener on the client side. When a test executes on the client side, it calls this socket to set the name of the executing test. The interceptor code on the server side queries the socket listener to ask what test it should run.

• Parameter-passing: by passing some parameters (test case name, etc) in the request to the server side.

There are pros and cons of each approach:

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 I have answered on the Cactus mailing list. Should this question be removed? -- VincentMassol

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? -- VincentMassol

Cactus2AlternatePropsoal -- ArchimedesTrajano