[eclipse-plugin] Container provider interface

[Christopher Lenz]

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).

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
- 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().

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.

Other questions remain: Where does the container provider get configuration info from? What needs to be configured on the container?
Candidates:
- Port: all containers have this option, should probably be stored in
the Cactus plugin preferences under a well known name.
- Work directory: some ContainerProvider impls might not need this,
others could do it transparently (java.io.tmpdir or sth)
- Anything else?

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.

-o-

Okay, this is just me brainstorming :-P

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 ;-)

--
Christopher Lenz
/=/ cmlenz at gmx.de


--
To unsubscribe, e-mail: <mailto:cactus-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:cactus-dev-help@;jakarta.apache.org>