> -----Original Message----- > From: Christopher Lenz [mailto:cmlenz@;gmx.de] > Sent: 21 October 2002 10:11 > To: Cactus Developers List > Subject: [eclipse-plugin] Container provider interface > > Hi Vincent, > > (opening a new thread as the other has gotten a bit long) > > Vincent Massol wrote: > > What do you think about implementing the interface you mentioned (with > > the install()/deploy()/start() and stop()) which in turn call Ant > > scriptlets. We probably still need a package() one to create the > > cactified war, no? > > Actually, I don't think so. Packaging the web-app is something that > shouldn't depend on the container. It's something the Eclipse plugin > must provide, but as an internal task (for example implemented by > calling a user-defined Ant target/script).
+1 completely. It should go in another interface, not the container one. > > Okay, about the provider interface, we have discussed four basic stages > that any implementation would need to provide: > > - startUp() > Sets up a new container instance, starts the container hum. Don't you think this should be divided in 2: - one method to install the container in a given directory - another one to start it > - deploy(webapp) > Deploys the specified web-application into the running container > - undeploy(webapp) > Removes the specified web-application > - shutDown() > Stops the container, cleans up any temp files > > This order already represents the lifecycle of a container provider > implementation. There could be an option like 'Keep container running > after the tests are completed', which would have the effect of multiple > calls to the deploy/undeploy-pair before shutDown/release. I could also > imagine removing the undeploy() hook, and just leaving it to the > provider impl to undeploy before doing a repeated deploy(). > yep > There is a difference to the sampe Ant scripts, which would usually look > like this: > - Prepare the container, package the web-app so that it gets > autodeployed when the container is started > - Start the container > - (Run the tests) > - Stop the container > The difference is that there is no explicit deployment going on after > the server has been started. And naturally, there are no means to > redeploy the webapp after it has been changed. We'd need to see how to > bridge this difference. Yes, but this is not a limitation of the Ant script. It can call the Tomcat manager application for example (there are actually ant tasks for that in Tomcat 4.1.x). But it depends on the app server. > > Other questions remain: Where does the container provider get > configuration info from? What needs to be configured on the container? I imagined a conf/ directory in the plugin, as in: conf/ |_ tomcat4x |_ resin2x |_ ... (same as what we have in servlet-sample) > Candidates: > - Port: all containers have this option, should probably be stored in > the Cactus plugin preferences under a well known name. yep. Idea is to store it in the plugin preference page but also ability to override it in the launch configuration (in a tabgroup). > - Work directory: some ContainerProvider impls might not need this, > others could do it transparently (java.io.tmpdir or sth) If we want to continue with the philosophy of installing the container in our own directory we definitely need this. I have proposed (in the PLAN.txt file) to put that info in the plugin preference page. > - Anything else? Home location of where the containers are installed. > > Specific containers can support additional config options, like basic > data for authentification etc. Such config would go into the preferences > of the Container plugin. Specifically, the Ant-based ContainerProvider > would need information about the Ant scripts and targets to be called in > the different stages. yes > > -o- > > Okay, this is just me brainstorming :-P very good! > > Having tight integration of Cactus in Eclipse would be sooooo nice. I > could imagine working on a ContainerProvider impl that uses an embedded > tomcat4/5 for max transparency and performance. That's why I'm pushing > for a flexible architecture ;-) Cool. Go for it! Flood us with patches for a while and then if you want we can add you as a committer to commit your patches by yourself! :-) BTW, have you seen the tight Jetty integration (which runs from inside the Cactus test) ? -Vincent -- To unsubscribe, e-mail: <mailto:cactus-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:cactus-dev-help@;jakarta.apache.org>
