[Cactus Plugin] Comments on IContainerProvider mechanism and co

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

Hi Julien,

Some comments:

1/ The interface must provide all needed parameters to the
implementation classes. ATM there are no parameters passed which makes
virtually impossible to provide an implementation. The Tomcat
implementation is "cheating" :-) as it is using hardcoded values.

2/ As a consequence of 1/ there should be a class containing all
container information (such as ContainerInfo or ContainerDetail):
- home directory
- port to use
- arbitrary parameters

3/ The API should be modified to include needed parameters:

    void start(ContainerInfo info) throws CoreException;
    void deploy(String contextPath, URL deployableObject(war or ear),
Credential credentials) throws CoreException;
    void undeploy(String contextPath, Credential credentials) throws
CoreException;
    void stop(ContainerInfo info) throws CoreException;

where Credential is a simple class containing username and password.

4/ Implementation package should be separated from interface package.

5/ We also need a way to create the war!

-Vincent


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [Cactus Plugin] Comments on IContainerProvider mechanism and co

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

> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 24 October 2002 20:37
> To: Cactus Developers List
> Subject: Re: [Cactus Plugin] Comments on IContainerProvider mechanism
and
> co
> 
> Howdy folks,
> 
> [some of this has been discussed on IRC, I'm trying to summarize here]
> 
> Vincent Massol wrote:
> > 1/ The interface must provide all needed parameters to the
> > implementation classes. ATM there are no parameters passed which
makes
> > virtually impossible to provide an implementation. The Tomcat
> > implementation is "cheating" :-) as it is using hardcoded values.
>  >
> > 2/ As a consequence of 1/ there should be a class containing all
> > container information (such as ContainerInfo or ContainerDetail):
> > - home directory
> > - port to use
> > - arbitrary parameters
> 
> If you view the IContainerProvider interface as an extension point
> exposed by the Cactus plug-in, implementations of the interface are
> potentially (and mostly) Eclipse plug-ins themselves. Thus, they
should
> have their own means of getting their configuration.

+1

> 
> What is passed into the IContainerProvider.start() should be
parameters
> that are *needed* for communication between the Cactus plug-in and the
> container provider plug-ins. One such parameter is the contextURL --
the
> container is required to listen to the same port that Cactus is
sending
> the test requests to, same with the context path if we don't want to
> hard-wire that.
> 

+1

> The home directory, OTOH is completely up to the container provider. A
> container provider plug-in that provides an embedded servlet container
> (such as Jetty) can do without a home directory. Others can ask the
user
> about the home directory in a preference page, for example. Most
> importantly, the Cactus plug-in itself does not need to know about the
> home directory, so it makes little sense to make it find out and later
> pass the information to the container provider. The same argument can
be
> applied for arbitrary (i.e. container-specific) parameters.
> 
> I think we need to get the concepts clear here. What I was proposing
> with a IContainerProvider extension point was to separate two
concerns:
>    - decorating the JUnit plugin so that Cactus test cases can be run
>    - providing a container in which the Cactus test cases can be run
> 
> The Cactus plug-in would take over responsibility for the first
concern:
> it hooks into some aspects of the JUnit plugin, to:
>    - provide the cactus.contextURL property
>    - package the components to deploy to container (war or ear)
>    - start the container before running the tests, stop the container
>      after the tests have completed
> 
> Because the last responsibility in that list is quite complex in
> reality, we want to delegate that to implementors of the
> IContainerProvider extension point. Their responsiblities would be:
>    - they *know* *how* to start/stop a concrete container, and do that
>      when the Cactus plug-in requests them to
>    - they also know how to deploy/redeploy components (webapps for
now)
>      to the container, and do that when the Cactus plug-in requests
them
>      to
> 
> Now, to take advantage of the existing Ant scripts in Cactus's
> sample-servlet, the Cactus plug-in would actually come with an
> implementation of the IContainerProvider interface. That
implementation
> might be called GenericAntContainerProvider, and it would have to be
> able to delegate all tasks to the corresponding Ant scripts/targets.

+1 to all.

> 
> > 3/ The API should be modified to include needed parameters:
> >
> >     void start(ContainerInfo info) throws CoreException;
> >     void deploy(String contextPath, URL deployableObject(war or
ear),
> > Credential credentials) throws CoreException;
> >     void undeploy(String contextPath, Credential credentials) throws
> > CoreException;
> >     void stop(ContainerInfo info) throws CoreException;
> >
> > where Credential is a simple class containing username and password.
> 
> I mostly agree about the delpoy/undeploy parameters.
> 
> > 4/ Implementation package should be separated from interface
package.
> 
> definitely.
> 
> > 5/ We also need a way to create the war!
> 
> yeah (ugh :-P)
> 

Cool. Thanks Chris for this nice summary and explanations!

Let's start rolling now ! :-)

-Vincent

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



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Cactus Plugin] Comments on IContainerProvider mechanism and co

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

Howdy folks,

[some of this has been discussed on IRC, I'm trying to summarize here]

Vincent Massol wrote:
> 1/ The interface must provide all needed parameters to the
> implementation classes. ATM there are no parameters passed which makes
> virtually impossible to provide an implementation. The Tomcat
> implementation is "cheating" :-) as it is using hardcoded values.
 >
> 2/ As a consequence of 1/ there should be a class containing all
> container information (such as ContainerInfo or ContainerDetail):
> - home directory
> - port to use
> - arbitrary parameters

If you view the IContainerProvider interface as an extension point 
exposed by the Cactus plug-in, implementations of the interface are 
potentially (and mostly) Eclipse plug-ins themselves. Thus, they should 
have their own means of getting their configuration.

What is passed into the IContainerProvider.start() should be parameters 
that are *needed* for communication between the Cactus plug-in and the 
container provider plug-ins. One such parameter is the contextURL -- the 
container is required to listen to the same port that Cactus is sending 
the test requests to, same with the context path if we don't want to 
hard-wire that.

The home directory, OTOH is completely up to the container provider. A 
container provider plug-in that provides an embedded servlet container 
(such as Jetty) can do without a home directory. Others can ask the user 
about the home directory in a preference page, for example. Most 
importantly, the Cactus plug-in itself does not need to know about the 
home directory, so it makes little sense to make it find out and later 
pass the information to the container provider. The same argument can be 
applied for arbitrary (i.e. container-specific) parameters.

I think we need to get the concepts clear here. What I was proposing 
with a IContainerProvider extension point was to separate two concerns:
   - decorating the JUnit plugin so that Cactus test cases can be run
   - providing a container in which the Cactus test cases can be run

The Cactus plug-in would take over responsibility for the first concern: 
it hooks into some aspects of the JUnit plugin, to:
   - provide the cactus.contextURL property
   - package the components to deploy to container (war or ear)
   - start the container before running the tests, stop the container
     after the tests have completed

Because the last responsibility in that list is quite complex in 
reality, we want to delegate that to implementors of the 
IContainerProvider extension point. Their responsiblities would be:
   - they *know* *how* to start/stop a concrete container, and do that
     when the Cactus plug-in requests them to
   - they also know how to deploy/redeploy components (webapps for now)
     to the container, and do that when the Cactus plug-in requests them
     to

Now, to take advantage of the existing Ant scripts in Cactus's 
sample-servlet, the Cactus plug-in would actually come with an 
implementation of the IContainerProvider interface. That implementation 
might be called GenericAntContainerProvider, and it would have to be 
able to delegate all tasks to the corresponding Ant scripts/targets.

> 3/ The API should be modified to include needed parameters:
> 
>     void start(ContainerInfo info) throws CoreException;
>     void deploy(String contextPath, URL deployableObject(war or ear),
> Credential credentials) throws CoreException;
>     void undeploy(String contextPath, Credential credentials) throws
> CoreException;
>     void stop(ContainerInfo info) throws CoreException;
> 
> where Credential is a simple class containing username and password.

I mostly agree about the delpoy/undeploy parameters.

> 4/ Implementation package should be separated from interface package.

definitely.

> 5/ We also need a way to create the war!

yeah (ugh :-P)

> -Vincent

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


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>