[eclipse-plugin] Container provider interface

[Christopher Lenz <cm...@gmx.de>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [eclipse-plugin] Container provider interface

[Vincent Massol <vm...@octo.com>]

> -----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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>