Hi Thomas, It'll take me some time to digest all this (the JIRA issue, your patch, the emails). ATM, I'm preparing my slides for Javapolis and I fear I won't have time to look at all this before end of next week. I hope this is fine and not too late with your own timeframe.
If someone else is interested in commenting please go ahead. Thanks -Vincent > -----Original Message----- > From: Th. Schapitz [mailto:[EMAIL PROTECTED] > Sent: jeudi 9 d�cembre 2004 11:52 > To: Cactus Developers List > Subject: Re: Remote Cactus, solved > > 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 > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
