Vincent Massol wrote:
To me, this looks like it would be totally sufficient, if all containers
supported the nested <startup> and <shutdown> tags, or something similar.
Could you be more explicit? (maybe I need to look at your patch first?).
From the point of view of usability, it might be best, if we deprecate <startup> and <shutdown> and reimplement these tags as subtags <beforeTest> <afterTest> in AbstractContainer, the rationale beeing, that the user remains free to choose, what ever he wants to do (deploying, bouncing the container) with what ever means he likes to utilize.
This would also avoid to introduce the cargo classes as dependency into Cactus.
Opinions?
Could you please give more context as I'm a bit lost to understand what you're suggesting. Are you talking about refactoring the existing <cactus> task? Are you talking about the current <runservertests> task? Are you talking about the <generic> nested element of the <cactus> task?
Yes, im talking about refactoring <cactus>, but not necessarily limited to <generic> (as my patch wasn't limited to <generic> too)
Hm, maybe this is because I didn't understand my Toolbox and the usage the manufracturer intended?
Anyway, I'm somewhat reluctant to impose my ideas on somebody, who might be the manufracturer himself, and might have had these ideas too ;-)
Ok, lets see how I typically do things: (Note, that in my own view, this is not exactly the most beautifull way, but it is, at times a manageable aproach)
a.) I keep my container running all the time (usually, it's a Weblogic)
b.) I ' m deploying using the the Weblogic deployer, via a <java fork="true" .... /> to avoid issues regarding the dependencies of weblogic.jar on a certain JRE version. (WLS 7.0 is tied to 1.3.1, WLS 8.1 is tied to 1.4.2.), Im doing this in a separte target, named foobar.deploy
c.) Im using the <cactus> task to start the test, and integrate the results into the non-cactus tests. The target containing the cactus task, has a dependency on foobar.deploy
d.) I'm *not* undeploying or bouncing the container, since I'm usually interested in doing some additional manual checks afterwards - or might get roughed up by dear coworkers using the same container.
As you might have guessed, this is tailored to the typicall usecase, you got in a corporate environment, where your tests are sometimes more than unit tests, because they cover part of the itegration.
However, even in this scenario, this might get us into maintainance hell, because we might need to adjust our build script or property files, every time we introduce a new container release.
Even more so, if: - you want to reuse the scripts to reiterate the tests on deployment on different staging areas within the same company - if you try to develop applications, that should run on J2EE containers of various providers (which I guess, was the intention behind introducing 'ContainerSet')
So I'm accepting, that there is not one best usage because of the number of different usecases out there, and opt for the right of choice.
This leaves us with he question how to allocate functionality in the trio of ANT, <cactus> and CARGO, and where to put container specific configuration data.
So my current notion of things as they are, is:
- Cactus ist the tool, to implement and run inContainer unit tests. - Cactus-Ant-Integration is the tool, to do this from within ant. - Cargo ist the tool, to start, stop and deploy on J2EE containers in an container independend fashion - Cargo-Ant-Integration is the tool, to do this from within ant.
Things could be pieced together in the ANT-Buildfile, but still that leaves us with the question:
Which of them is going to provide the infrastructure necessary to make the execution of tests container independent? Surely, this issue is more pressing, if you are relying on your tests being run on the same maschine or even the same VM for some reason.
Currently, both Cargo and Cactus-Ant-Integration provide a means to hold container specific data. In Catus, its the interface 'Container' and its derivations.
What I suggest now, is relieving the <cactus> task at least completely of the deployment / startup / shutdown part.
The means for that could be ANT itself, using the interface org.apache.tools.ant.TaskContainer. ASFAICT, an attribute derived from there could contain any sequence of tasks.
I think you allready did somthing very simlar by introducing the inner class GenericContainer.Hook
Moving this to AbstractContainer, and ajusting the name to beforeTest / afterTest would make this available to all derived container types, and removing the notion of beeing fit only for startup and shutdown.
In short, I think this option has the benefits of beeing - the smallest effort, while achieving the full goal - leaving all options open for ANT users
What I would like to see from CARGO though, is some sort of custom Ant Type, holding container related data, that can be set up in advance like a fileset or classpath, hopefully by refering to a separate property file.
Something like this would come in handy, if the deployment, start and stop tasks are spread all over the build.xml, and would also serve separating the container setup from the build file.
It might even help somebody who's willing to unifying the view to EJBC and JSPC. (Didn't see this on the agenda of CARGO. Is it?)
Let me know, if you want me to implement the change to to AbstractContainer in a follow up patch.
Regards, Thomas
